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INTER-SERVER COMMUNICATION USING 
REQUEST WITH ENCRYPTED PARAMETER 

CROSS-REFERENCE TO RELATED CASES 

This application claims the benefit of U.S. Provisional Application No. 
5 60/172,318 entitled "System for Distributing Content Having Multilevel Security 
Protection," and U.S. Provisional Application No. 60/172,319 entitled "System and 
Method for Digital Rights Management," both filed on December 17. 1999. 

FIELD OF THE INVENTION 

The present invention relates generally to the field of computing, and 
10 more particularly to a technique for inter-server communication using a type of request 
having an encrypted parameter. 

BACKGROUND OF THE INVENTION 

As the availability and use of computers and palm-sized electronic 
devices has increased, it has become common for documents to be transmitted and 

15 viewed electronically. With improving communication over infirastructures such as the 
Internet, there is a tremendous drive to provide enhanced services and content to the 
devices. Examples of services and content that may be provided are authored works, 
such as books or other textual material. Electronic distribution of text documents is both 
faster and cheaper than conventional distribution of paper copies. The same principle 

20 applies to non-textual content, such as audio and video: electronic distribution of such 
content is generally faster and cheaper than the delivery of such content on conventional 
media (e.g., magnetic tape or optical disk). However, the low cost and instantaneity of 
electronic distribution, in combination with the ease of copying electronic content, is at 
odds with the goal of controlled distribution in a manner that protects the rights of the 

25 owners of the distributed works. 

Once an electronic document is transmitted to one party, it may be easily 
copied and distributed to others without authorization by the owner of rights in the 
electronic document or, often, without even the owner's knowledge. This type of illicit 
document distribution may deprive the author or content provider of royalties and/or 
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income. A problem with many present delivery schemes is that they may make no 
provisions for protecting ownership rights. Other systems attempt to protect ownership 
rights, but however, are cumbersome and inflexible and make the viewing/reading of the 
authored works (or otherwise rendering the authored works, in the case of non-text 
5 content such as music, video, etc.) difficult for the purchaser. 

Thus, in view of the above, there is a need for an improved digital rights 
management system that allows of delivery of electronic works to purchasers in a 
maimer that protects ownership rights, while also being flexible and easy to use. There is 
also a need for the system that provides flexible levels of security protection and is 

1 0 operable on several client platforms such that electronic content may be viewed/rendered 
by its purchaser on each platform. The digital rights management system of the present 
invention advantageously provides solutions to the above problems which protect the 
intellectual property rights of content owners and allow for authors or other content 
owners to be compensated for their creative efforts, while ensuring that purchasers are 

15 not over-burdened by the protection mechanism. 

SUMMARY OF THE INVENTION 

A server architecture is provided which supports the distribution of 
protected content in a digital rights management ("DRM") system. The architecture 
includes an activation server arrangement, and a distribution server arrangement. The 

20 architecture includes various security features that guard against unauthorized 

distribution or use of protected content, as well as software components that implement 
the security features. 

In accordance with the architecture provided, content may be protected at 
a plurality of levels, including: no protection, source sealed, individually sealed (or 

25 "inscribed"), source signed, and fiilly individualized (or "owner exclusive"). "No 
protection" content is distributed in an unencrypted format. "Source sealed" and 
"individually sealed" content is encrypted and bundled with an encryption key that is 
cryptographically sealed with certain rights-management data associated with the 
content, such that the key cannot be retrieved if the rights-management data has been 

30 altered. The distinction between "source" and "individual" sealing is that "individually 
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sealed" content includes in the rights-management data information pertinent to the 
rightful owner (e.g., the owner's name, credit card number, receipt number or transaction 
ID for the purchase transaction, etc.), such that this information cannot be removed from 
a working copy of the content, thereby allowing for detection of unauthorized 
5 distributors. The particular type of information included is determined by the retailer of 
the copy. "Signed" content is cryptographically signed in such a way that the rendering 
application can verify its authenticity, or the authenticity of its distribution channel. 
"Fully individualized" content is encrypted content provided with a decryption key that 
has not merely been sealed with the rights-management information, but also encrypted 

10 in such a way that it cannot be accessed in the absence of a "secure repository" and 
"activation certificate," which are issued by the activation server arrangement only to a 
particular client or set of clients, thereby limiting the use of such content to a finite 
number of installations. 

The activation server arrangement includes one or more server computing 

15 devices which "activate" client computing devices by providing code and data to these 
devices, where the code and data are necessary to access "fully individualized" content 
on a given client device. In one example, the "data" includes an activation certificate 
having a public key and an encrypted private key, and the "code" is a program (e.g., a 
"secure repository") that accesses the private key in the activation certificate by 

20 applying, in a secure manner, the key necessary to decrypt the encrypted private key. 
Preferably, the key pair in the activation certificate is persistently associated with an 
authenticatable "persona," such that a device can be "activated" to read content that has 
been individualized for that persona, but not content that has been "fully individualized" 
for other personas. As used herein, a "persona" is a imique identifier that can be tied to a 

25 user and can be securely authenticated by an out-of-band process - e.g., a usemame and 
password form on a web browser for use over a secure socket layer (SSL) is an example 
embodiment of such a process. Moreover, the activation server arrangement preferably 
provides a given activation certificate (that is, an activation certificate having a particular 
key pair) only after authenticating credentials (e.g., a usemame and password) associated 

30 with a persona. In accordance with a feature of the invention, the number of devices that 
a particular persona may activate may be limited by rate and or by number (e.g., five 
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activations within a first 90 day period, followed by an additional activation for every 
subsequent 90 day period, up to a maximum of ten activations), thereby preventing the 
imchecked proliferation of devices on which individualized content can be rendered. As 
one example use of this technique, protected content may be distributed as a file that 
5 includes content encrypted with a symmetric key, where the symmetric key itself is 
provided via a license construct embedded in the file in a form encrypted by the 
certificate's public key, thus making it necessary to have both the activation certificate 
and accompanying secure repository prior to interacting with the licensed content. 

The distribution server arrangement includes one or more retail servers 
and one or more fulfillment sites. Retail servers sell protected content (or otherwise 
enUst users to receive protected content). Fulfillment sites provide the actual content that 
has been sold by the retail servers. The operator of a retail server may be a different 
entity from the operator of a fiilfilhnent site, thereby making it possible for a retailer to 
sell protected content simply by entering into an agreement whereby a fiilfiUment site 
will provide content sold by the retailer. This allows the retailer to sell content without 
investing in the means to store or distribute the content. In one example, the retailer and 
the fiilfiUment site agree on a secret (e.g., a cryptographic key), and the retailer equips its 
server with software that uses the secret to create an encrypted instruction to provide the 
content to the purchaser. The retailer may then allow the purchaser to **fiilfiir' his or her 
purchase by providing an HTTP request to the purchaser (e.g., a POST request rendered 
as a hyperlink on a "receipt" or "confirmation" web page), where the HTTP request 
contains the address of the fiilfiUment site and the encrypted instruction. In the case of 
content requiring some level of individuaUzation, the encrypted instruction may include 
the individualization information (e.g., the purchaser's name, or, in the case of "fiiUy 
individualized" content, the purchaser's activation certificate). The fiilfiUment site 
receives the encrypted instruction when the purchaser clicks on the link, and the 
fulfilhnent site uses the shared secret to decrypt the instruction and provide the content in 
accordance therewith. A component object model (COM) object may be provided to the 
retailer which creates the encrypted instruction. 

The fiilfiUment site may be organized as a fiilfilhnent server plus one or 
more "download" servers and a content store. The content store stores content to be 
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distributed to consumers. The fiilfillment server maintains databases of information 
related to the fulfillment of content orders, such as the physical location of content items 
and the secret (e.g., the cryptographic key) necessary to decrypt instructions received 
from the retailer. The download servers perform the actual downloading of content to 
5 consumers/purchasers of the content, as well as any preparation of the content that is 
necessary to meet the protection requirements associated with the content (e.g., the 
download server may perform individualization of the content). Each download server 
may have a cache, where the download server obtains a copy of a content item from the 
content store (in accordance with the location specified in the fulfilhnent server database) 

10 the first time that download server is called upon to process a download of that item, 
where the download server stores the item in the cache for future downloads. The cache 
may have limits associated therewith, and it may expire items out of the cache based on 
an algorithm such as a "least recently used" algorithm. The download server may also 
provide information regarding the downloads that it processes to the fulfillment server 

1 5 for entry into a log. The download server may provide this information in the form of 
messages through an asynchronous messaging, such as MICROSOFT MESSAGE 
QUEUE (MSMQ). The fulfillment server may store the information in a "logging 
database." Additionally, when updates to information stored on the fulfilhnent server are 
made which affect the content item stored in the cache, the fulfillment server may use the 

20 messaging service to send messages to the various download servers indicating that the 
item should be invalidated in the download server caches. 

Other features of the invention are described below. 

BRIEF DESCRIPTION OF THE DRAWINGS 

The foregoing summary, as well as the following detailed description, is 
25 better understood when read in conjunction with the appended drawings. For the purpose 
of illustrating the invention, like references numerals represent similar parts throughout 
the several views of the drawings, it being understood, however, that the invention is not 
limited to the specific methods and instrumentalities disclosed. In the drawings: 

FIG. 1 is an exemplary electronic book (eBook) title file format; 
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FIG. 2 is a block diagram showing an exemplary computing environment 
in which aspects of the present invention may be implemented; 

FIG. 3 is a block diagram of an embodiment of a first server architecture 
implementing aspects of a digital rights management system in accordance with the 
5 invention; 

FIG. 4 is a block diagram of an embodiment of a second server 
architecture implementing aspects of a digital rights management system in accordance 
with the invention; 

FIG. 5 is a block diagram illustrating certain interactions within a content 
10 provider server in accordance with aspects of the invention; 

FIG. 6 is a block diagram showing components of an asynchronous 
fulfillment pipeline in accordance with aspects of the invention; 

FIG. 7 is a flow diagram illustrating the process of generating a license in 
accordance with aspects of the invention; 
15 FIG. 8 is a flow diagram illustrating a client reader activation process in 

accordance with aspects of the invention; and 

FIGS. 9 and 10 are flow and block diagrams illustrating an eCommerce 
flow in accordance with aspects of the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

20 The present invention is directed to a system for processing and delivery 

of electi-onic content wherein the content may be protected at multiple levels. A preferred 
embodiment of the invention is described, which is directed to the processing and 
delivery of electronic books, however, the invention is not limited to electronic books 
and may include all digital content such as video, audio, software executables, data, etc. 

25 Overview 

The success of the electronic book industry will undoubtedly require 
providing the existing book-buying public with an appealing, secure, and familiar 
experience to acquire all sorts of textual material. This material may include "fi-ee" or 
low-cost material requiring little copy protection, to "premium-quality" electronic book 

30 titles (herein "eBooks") requiring comprehensive rights protection. In order to enable a 
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smooth transition from the current distribution and retail model for printed books into an 
electronic distribution system, an infrastructure must exist to ensure a high level of copy 
protection for those publications that demand it, while supporting the distribution of titles 
that require lower levels of protection. 
5 The Digital Rights Management (DRM) and Digital Asset Server (DAS) 

systems of the present invention advantageously provides such an infrastructure. The 
present invention makes purchasing an eBook more desirable than "stealing" (e.g., 
making an unauthorized copy of) an eBook. The non-intrusive DRM system minimizes 
piracy risk, while increasing the likelihood that any piracy will be offset by increased 

10 sales/distribution of books in the form of eBooks. In addition, the present invention 
provides retailers with a system that can be rapidly deployed at a low-cost. 

The primary users of the DRM System are publishers and retailers, who 
use and/or deploy the DRM System to ensure legitimacy of the content sold as well as 
copy protection. Exemplary users of the DRM System may be the traditional publisher, 

15 the "leading edge" publisher, and the "hungry author." The traditional publisher is likely 
to be concerned about losing revenue from their printed book publishing operation to 
eBook piracy. The leading edge publisher is not necessarily concerned with isolated 
incidents of piracy and may appreciate that eBooks commerce will be most successfiil in 
a system where consumers develop habits of purchase. Meanwhile, the hungry author, 

20 who would like to collect money for the sale of his or her works, is more interested in 
attribution (e.g., that the author's name be permanently bound to the work). 

As will be described in greater detail below, the DRM System of the 
present invention accomplishes its goals by protecting works, while enabling their 
rightful use by consumers, by supporting various "levels" of protection. At the lowest 

25 level ("Level 1 "), the content source and/or provider may choose no protection via 

unsigned and unsealed (clear-text) eBooks that do not include a license. A next level of 
protection ("Level 2") is "source sealed," which means that the content has been 
encrypted and sealed with a key, where the seal is made using a cryptographic hash of 
the eBook*s title's meta-data (see below) and the key is necessary to decrypt the content, 

30 Source sealing guards against tampering with the content or its accompanying meta-data 
after the title has been sealed, since any change to the meta-data will render the title 
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unusable; however, source sealing does not guarantee authenticity of the a copy of the 
title (i.e., source sealing does not provide a mechanism to distinguish legitimate copies 
from unauthorized copies). In the case of the "hungry author," the author's name may be 
included in the meta-data for permanent binding to the content, thereby satisfying the 
5 "hungry author's" goal of attribution. A next level of protection ("Level 3") is 

"individually sealed" (or "inscribed"). An "individually sealed" title is an eBook whose 
meta-data includes information related to the legitimate purchaser (e.g., the user's name 
or credit card number, the transaction ID or receipt number from the purchase 
transaction, etc.), such that this information is cryptographically bound to the content 
10 when the title is sealed. This level of protection discourages people from distributing 
copies of the title, since it would be easy to detect the origin of an unauthorized copy 
(and any change to the meta-data, including the information related to the purchaser, 
would make it impossible, or at least improbable, that the necessary decryption key could 
be unsealed). 

15 The next level of protection ("Level 4") is "source signed." Source signed 

eBooks are titles that can be authenticated by a "reader" (which, as more particularly 
discussed below, is a user application that enables the reading of eBooks on a computing 
device, such as a PC, a laptop, a Personal Digital Assistant (PDA), PocketPC, or a 
purpose-built reading device). Authenticity may preferably be defined in three varieties: 

20 "tool signed," which guarantees that the eBook title was generated by a trusted 

conversion and encryption tool; "owner signed," which is a tool signed eBook that also 
guarantees the authenticity of the content in the copy (e.g., the owner may be the author 
or other copyright holder); and "provider signed," which is a tool signed eBook that 
attests to the authenticity of its provider (e.g., the publisher or retailer of the content). 

25 The "tool," the owner, and the provider may each have their own asymmetric key pair to 
facilitate the creation and validation of digital signatures of the information. A title may 
be both provider signed and source signed, which facilitates authentication of the 
distribution channel of the title (e.g., through a signature chain in the copy). The 
strongest level of protection is "fully individuahzed" or "owner exclusive" ("Level 5"). 

30 "Fully individuahzed" titles can only be opened by authenticated reader applications that 
are "activated" for a particular user, thereby protecting against porting of a title from one 
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person's reader (or readers) to a reader that is not registered to that person. In order for 
the reader of the present invention to open a title protected at Level 5, the Reader must be 
"activated" (i.e., the device on which the reader resides must have an activation 
certificate for a particular persona, and a secure repository). The process of activation is 
5 described in greater detail below with reference to Fig. 8. 

The systems of the present invention also define an architecture for 
sharing information between a reader, a content provider and a content source, how that 
information is used to "seal" titles at the various levels, and how that information must 
be structured. The availability of these choices will enable content sources to pick and 
10 choose which content will be sold to what users and using what protection (if any). The 
particular information may be used to sign and/or seal titles for use by a reader, and a 
compatible reader (which, in the case of level 5, may be a reader activated for a 
particular persona) may unseal the title and enable reading of the eBook. 
eBook File Structure 

The DRM system of the present invention protects content by 
incorporating it in a file structure, such as the exemplary structure shown in FIG. 1. 
Referring to FIG. 1, eBook 10 contains content 16, which is text such as a book (or any 
electronic content) that has been encrypted by a key (the "content key"), which itself has 
been encrypted and/or sealed. In a preferred embodiment, the key is a symmetric key 
14A that is sealed with a cryptographic hash of meta-data 12 or, in the case of level 5 
titles, with the public key of the user's activation certificate. This key is stored either as a 
separate stream in a sub-storage section of the eBook file (DRM Storage 14 in the 
diagram) or, in the case of level 5 titles! in the license. (In the case of level 5 titles, 
instead of storing the content key as a separate stream, stream 14A contains a license, 
which is a construct that defines the rights that the user can exercise upon purchase of the 
title. In titles that have a license, the content key is contained witiiin the license.). Also 
included in the DRM storage 14 are the source stream 14B, which may include the name 
of the publisher (or other content source), as well as the bookplate stream 14C, which, 
for individually sealed (level 3 and/or level 5) titles, includes die consumer's name as 
provided by the retailer (which may, for example, be obtained as part of the commercial 
transaction of purchasing an eBook 10, such as firom the consumer's credit card 
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information). The method of calculating the cryptographic hash that encrypts and/or 
seals the symmetric key 14C (or the method of using such cryptographic hash to seal the 
key) is preferably a "secret" known only to trusted content preparation tools and trusted 
rendering applications. Using a hash in this way may complicate/discourage tampering 
5 with the meta-data 12 contained with the eBook 10. It is noted that any method may be 
used to "seal" an eBook, so long as such method provide some measure of tamper 
resistance to the eBook 10. 

In accordance with the present invention, the meta-data 12 may include a 
copyright tag, which describes the rights granted to the user or purchaser by the content 
source (e.g., the publisher). Whenever such tag is present, the client (e.g., device 90 or 92 
shown in FIG. 4) may display to a user the text included in the tag. It will be appreciated 
that the act of reminding users of the copyright laws that apply to their eBooks may 
serves to deter typical users from attempting to copy eBooks. 
DRM System Architecture 

As shown in FIG. 2, an exemplary system for implementing the invention 
includes a general purpose computing device in the form of a conventional personal 
computer or network server 20 or the like, including a processing unit 21, a system 
memory 22, and a system bus 23 that couples various system components including the 
system memory 22 to the processing unit 21. The system bus 23 may be any of several 
types of bus structures including a memory bus or memory controller, a peripheral bus, 
and a local bus using any of a variety of bus architectures. The system memory includes 
read-only memory (ROM) 24 and random access memory (RAM) 25. A basic 
input/output system 26 (BIOS), containing the basic routines that help to transfer 
information between elements within the personal computer 20, such as during start-up, 
is stored in ROM 24. The personal computer or network server 20 may further include a 
hard disk drive 27 for reading from and writing to a hard disk, not shown, a magnetic 
disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical 
disk drive 30 for reading from or writing to a removable optical disk 31 such as a 
CD-ROM or other optical media. The hard disk drive 27, magnetic disk drive 28, and 
optical disk drive 30 are cormected to the system bus 23 by a hard disk drive interface 
32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively. 
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The drives and their associated computer-readable media provide non-volatile storage of 
computer readable instructions, data structures, program modules and other data for the 
personal computer or network server 20. Although the exemplary environment described 
herein employs a hard disk, a removable magnetic disk 29 and a removable optical disk 
5 3 1 , it should be appreciated by those skilled in the art that other types of computer 
readable media which can store data that is accessible by a computer, such as magnetic 
cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access 
memories (RAMs), read-only memories (ROMs) and the like may also be used in the 
exemplary operating environment. 

10 A number of program modules may be stored on the hard disk, magnetic 

disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35 (e.g., 
Windows® 2000, Windows NT®, or Windows 95/98), one or more application 
programs 36, other program modules 37 and program data 38. A user may enter 
commands and information into the personal computer 20 through input devices such as 

15 a keyboard 40 and pointing device 42. Other input devices (not shown) may include a 
microphone, joystick, game pad, sateUite disk, scanner or the like. These and other input 
devices are often coimected to the processing unit 21 through a serial port interface 46 
that is coupled to the system bus 23, but may be connected by other interfaces, such as a 
parallel port, game port, universal serial bus (USB), or a 1394 high-speed serial port. A 

20 monitor 47 or other type of display device is also connected to the system bus 23 via an 
interface, such as a video adapter 48. In addition to the monitor 47, personal computers 
typically include other peripheral output devices (not shown), such as speakers and 
printers. 

The personal computer or network server 20 may operate in a networked 
25 envirormient using logical connections to one or more remote computers, such as a 
remote computer 49. The remote computer 49 may be another personal computer, 
another network server, a router, a network PC, a peer device or other common network 
node, and typically includes many or all of the elements described above relative to the 
personal computer 20, although only a memory storage device 50 has been illustrated in 
30 Fig. 2. The logical connections depicted in Fig. 2 include a local area network (LAN) 51 
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and a wide area network (WAN) 52. Such networking environments are commonplace in 
offices, enterprise-wide computer networks, Intranets and the Internet. 

When used in a LAN networking environment, the personal computer or 
network server 20 is connected to the local network 51 through a network interface or 
5 adapter 53. When used in a WAN networking environment, the personal computer or 
network server 20 typically includes a modem 54 or other means for establishing 
commxmications over the wide area network 52, such as the Internet. The modem 54, 
which may be internal or external, is connected to the system bus 23 via the serial port 
interface 46. In a networked environment, program modules depicted relative to the 
10 personal computer or network server 20, or portions thereof, may be stored in the remote 
memory storage device 50. It will be appreciated that the network connections shown are 
exemplary and other means of establishing a commimications link between the 
computers may be used. 

Server Architecture 

15 Referring now to FIG. 3, there is illustrated a first exemplary server 

architecture 70 implementing the DRM System of the present invention. Server 
architecture 70 is implemented and deployed at, for example, a retail/distribution site. In 
one embodiment of the invention, all components of server architecture 70 are associated 
with a single party (e.g., a large electronic bookstore) that both retails eBooks 10 and 

20 performs the actual download of eBooks 10 to customers' reading devices. In another 
embodiment of the invention, the bookstore servers 72 and the URL encryption COM 
object 74 are associated with one party (e.g., a retailer of eBooks 10 who does not 
perform downloads), and the other components of server architecture 70 are associated 
with a second party (e.g., a "fulfilhnent house"), which performs downloads of eBooks 

25 10 that are sold/retailed by the first party. 

The functions provided by the server architecture 70 include; encryption 
of source eBooks, conversion to the target reader format, generation of the license 
construct defining the rights granted to the user (in level 5 titles), sealing of the content 
prior to download in accordance with requirements (e.g., a level of protection) set forth 

30 by the publication provider, and download of eBook titles. This server architecture also 
includes features that provide for a flexible configuration that enables the users of this 
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technology (content providers, retailers) to scale their system according to their needs. 
These features include: dynamic resolution (through a database lookup) of file IDs to 
physical file locations, in-memory caching of the most popular downloads for higher 
efficiency and better performance (where the cache may expire items based on, e.g., a 
5 least-recently-used fimction), and asynchronous logging of each downloaded file (also to 
a database) for later auditing/reporting and/or billing purposes. Other fimctions may be 
performed by the server architecture 70 in accordance with the present invention. 

Bookstore servers 72 preferably are MICROSOFT® Internet Information 
Server (IIS) servers implemented on a network server, such as computer 20 illustrated in 
Fig. 2. Bookstore servers 72 may communicate with users via web browsing software 
(e.g., by providing web pages for viewing with a MICROSOFT INTERNET 
EXPLORER browser or a NETSCAPE NAVIGATOR browser). Through this 
communication, bookstore servers 72 may allow users to shop for eBook titles, establish 
their membership relationship with the retailer, pay for their transactions, and access 
proof-of purchase pages (serve-side receipts). URL encryption object 74 may reside on 
bookstore servers 72. URL encrypt object 74 encrypts a set of parameters relating to an 
eBook 10 that has been purchased on bookstore server 72. URL encryption object 74 
may encrypt these parameters using a secret (e.g., a symmetric cryptographic key) shared 
between bookstore server 72 and web content server 76. For example, the parameters 
may include an identification of the eBook purchased, information about the purchase 
such as the purchaser's name or credit card nvunber or a transaction ID (e.g., in the case 
of level 3 or 5 titles), and a timestamp. It will be appreciated by those skilled in the art 
that the parameters listed above are exemplary, and different parameters could be used 
without departing from the spirit and scope of the invention. The encrypted parameters 
may be included in an HTTP request that points to web content server 76, such that 
content server 76 can fulfill the purchase made at bookstore server 72. For example, after 
an eBook 10 has been selected by a purchaser, bookstore server 72 could upload to the 
purchaser's computing device a web page containing a link associated with a POST 
request, where the POST request points to a content server such as ' Svww.content- 
provider.com ", and the body of the POST contains the encrypted parameters. In an 
^alternative embodiment of the invention, the link provided on the web page could be 
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associated with a GET request, such as " http://www.content- 

provider.com/isapi/ds.dll?action=download&value=<encrypted parameters> ," although 
this ahemative embodiment has the disadvantage that some browsers place a hmit on the 
acceptable size of a URL (e.g., 2 kilobytes), thereby restricting the size of the encrypted 
5 parameters. Whichever type of HTTP request is associated with the link, the user could 
then follow the link to initiate the download. Because the parameters have been 
encrypted with a secret shared between bookstore server 72 and content server 76, it is 
possible for content server 76 to verify that the encrypted parameters originated at a 
legitimate bookstore server 72 (e.g., one for which the operator of content server 76 has 

10 agreed to provide download services). If a timestamp is included, then content server 76 
can use the timestamp to ensure that the encrypted parameters were recently generated, 
thereby resisting "playback attacks" (i.e., by "sniffing" of the HTTP request by one who 
wants to download eBooks that he or she has not rightfully purchased). URL encryption 
object 74 is preferably implemented as a server- side COM object, and is preferably 

1 5 instantiated via Active Server Pages (ASP). 

The content servers 76 are preferably IIS servers implemented on a 
network server (preferably different fi-om bookstore server 72). Like bookstore server 72, 
content server 76 may be implemented on a computer such as computer 20 shown in Fig. 
2. A download server ISAPI Extension 78 is provided, which is an US extension DLL 

20 that preferably handles the incoming requests to the content servers 76. The ISAPI DLL 
78 is responsible for vaHdating download requests, retrieving the appropriate eBook file 
10 from the content store 80 via content store plug-in module 88, individually sealing 
copies, returning the eBook titles 10 to the end-users, and logging the transaction into the 
fulfilhnent database 84 via an asynchronous messaging module. MICROSOFT Message 

25 Queue (MSMQ) independent client 86 is an exemplary asynchronous messaging module 
that may be used in server architecture 70 (and server architecture 70' depicted in FIG. 4 
and discussed below). While use of Microsoft's MSMQ technology is preferable for 
asynchronous commimication of its server-to-server messages (MSMQ Client 86), it will 
be appreciated by those skilled in the art that any store-and-forward messaging 

30 technology may be used. According to one aspect of server architecture 70 (and 
architecture 70'), such resilient messaging technology may be used to achieve high 
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degrees of reliability and scalability, since all server to server messaging that does not 
require real-time communications is carried out using an asynchronous communications 
pipeline. 

Content store 80 is preferably a large, network attached file system or 
5 database management system (or a plurality of such file systems or database 

management systems). Content store 80 serves as a repository for LIT titles (eBooks 10) 
used by the download server ISAPI 78 when fulfilling orders for eBooks 10. Content 
store 80 preferably exposes a Universal Naming Convention (UNC) path that can be 
accessed by download server ISAPI 78. For security reasons, it is preferable that content 

10 store(s) 80 exist behind a firewall and not be exposed directly to the Internet. Content 
management and encryption tool 82 is a component that performs fiinctions such as 
convertmg content to the LIT format (e.g., eBook 10), encrypting and sealing each 
eBook title on the content store 80. Content management and encryption tool 82 also 
updates fiilfilbnent database 84 with the physical location of each LIT file on the content 

15 store 80, which is mapped to their unique ID on the fiilfiUment database 84. Tool 82 

accepts clear-text source files (LIT, OEB, HTML, etc.) and generates encrypted LIT files 
that are source sealed (e.g., level 2), for later retrieval by the download server ISAPI 78. 

Referring now to FIG. 4, there is illustrated a second server architecture 
70* in accordance with the present invention. Server architecture 70' is a distributed 

20 model, and includes three data centers: a retail site 71, a DRM & fulfillment site 73, and 
an activation site 75. As with server architecture 70, retail of content and fiilfiUment of 
content orders may be performed by a single party, or a first party may retail eBooks 10 
while a second party fulfills orders for eBooks 10 that were sold by the first party. In this 
latter scenario, retail site 71 is associated with the first party, and DRM & fiilfiUment site 

25 73 is associated with the second party. Within the architecture of FIG. 4, it is preferable 
that all web server-based applications be clustered behind a virtual IP address, and that 
content servers be dual-homed. It is also preferable that activation servers 94 rely on the 
MICROSOFT® PASSPORT^" membership system for associating activation certificates 
to end-user personas, as will be described below (although PASSPORT is merely 

30 exemplary of a namespace authority that may be used for this purpose). 
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The following is a brief description of the components of server 
architecture 70'. Bookstore servers 72 associated with retail site 71 are network servers 
implemented on a computer such as computer 20. Preferably, bookstore servers 72 run 
WINDOWS® 2000 Advanced Servers running IIS. As in architecture 70, these servers 
5 host the commercial web site that allow users to perform actions such as shopping for 
eBook titles, establishing their membership relationship with the retailer, paying for their 
transactions, and/or accessing the proof of purchase pages (server-side receipts). URL 
encryption object 74 is provided for integration into the retailer site 71. As in server 
architecture 70, the URL encryption object 74 of server architecture 70' may be 

10 implemented as a server-side COM object installed on the bookstore servers 72 and 
instantiated via ASP pages, and it may encrypt parameters relating to the purchase of an 
eBook 10 such that content server 76 may validate the encrypted parameters, 
authenticate the retailer via a shared secret (e.g., a symmetric key used to encrypt the 
parameters), avoid playback attacks, and determine the content to download to end-users. 

1 5 Content server(s)/download server(s) 76 are preferably WINDOWS® 

2000 Advanced Servers running nS. Content servers/download servers 76 host the core 
components of the DAS fulfillment application, including download server ISAPI 
extension 78, content store plug-in module 88, license server module 77, and fuifiihnent 
pipeline client 86. 

20 As noted above, the download server ISAPI Extension 78 is preferably an 

nS extension DLL that handles incoming requests to the content servers 76. It is 
responsible for validating each download request, individually sealing copies (when 
necessary), requesting a license for fully individualized (i.e., level 5) copies of eBooks, 
returning the eBook titles to the end-users, and logging the download transaction in a 

25 database, such as logging database 91 . 

The content store plug-in module 88 is preferably a DLL which is 
responsible for determining the physical location on the content store 88 of each of the 
LIT files (eBooks) being downloaded, based on a combination of parameters (e.g., book 
ID and book ID type parameters) included on the download request (i.e., the encrypted 

30 parameters attached to the URL). Plug-in module 88 also retrieves, from fiilfilknent 
database 89, configuration information (e.g., the licensor's private key and public key 
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certificate, a list of retailers supported and their symmetric keys, etc.) required to 
bootstrap the download server IS API extension DLL 78. 

License server module 77 is a sub-component of the download server 
ISAPI extension DLL 78. It is responsible for generating and sealing licenses for level 5 
5 protected LIT files. As more fully described below, a license is a construct that defines 
the rights that the rights that the user may exercise upon purchase of an eBook title. 
License server module 77 also validates the activation certificate of the user to whom the 
eBook is being downloaded and signs each license with the private key of the fulfillment 
center provider, which will later allow reader 90 or 92 to authenticate the distribution 

10 channel when the dovmloaded LIT file is accessed on such reader. Exemplary readers are 
fully described in Attorney's Docket No. MSFT-0123, filed concurrently herewith, 
which is expressly incorporated herein by reference in its entirety. 

The fulfilhnent pipeline client 86 is preferably a MICROSOFT® Message 
Queue (MSMQ) independent client, which is available with the WINDOWS® 2000 

15 Server product family. This component implements the asynchronous communications 
pipeline between the download Server ISAPI 78 and the fulfillment database 89. The 
ISAPI 78 logs each download transaction via a message posted to the local MSMQ client 
86 on each content server 76, which in turn will store and forward such message in a 
resilient form to a sunilar MSMQ client 86 hosted on the fulfillment server 84. This 

20 pipeline will also be used for invalidating cached entries on an ISAPI RAM cache 

(located on content servers 76), via messages that are posted fi:-om the fulfillment server 
84 to the ISAPI DLL 78 via the same set of locally hosted MSMQ clients. 

As in server architecture 70, the content store 80 of server architecture 70' 
is preferably a large, network attached file system or database management system. It 

25 serves as a repository for the LIT titles used by the download server ISAPI 78 when 
fulfilling the orders. This server preferably runs WINDOWS® 2000 Advanced Server 
and exposes a UNC path that can be accessed by the download server ISAPI DLL, This 
may be accomplished via a setup application provided by DAS. It is also preferable that 
the content store 80 exists behind a firewall and is not exposed to the Web. 

30 The fiilfillment server 84 is preferably a WINDOWS 2000 Advanced 

Server running MICROSOFT® SQL 7.0 (or later). This server hosts a fulfillment 
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database 89, a logging database 91, a fulfillment pipeline client 86, and a fulfillment 
pipeline COM object 87. Fulfillment database 84 hosts tables that map the combination 
of a ^'Book ID" and "Book JD Type" to the physical location of each LIT file on content 
store 80. Database 84 also contains information about each LIT file that may be required 
5 for fulfillment, such as the book title, the book author, DRM protection level, and/or 
suggested retail price. The full range of information may vary in accordance with the 
business rules/practices of each fulfilhnent center (e.g., the entity that operates content 
server 76), but preferably the information includes those items listed above. A command- 
line script may be provided that creates the necessary tables and stored procedures for 

10 this database, in addition to adding sample entries that can be used as reference by the 
fulfillment center when designing their content management processes. 

Logging database 91 is used for logging each download transaction from 
the download server ISAPI DLL 78 (for later billing/reporting when applicable). The 
fiilfillment pipeline client 86 is preferably a MICROSOFT® Message Queue (MSMQ) 

15 independent client which exists on the content/download servers 76, as described above. 
The fulfillment pipeline object 87 is preferably a COM object that is triggered by the 
MSMQ independent client hosted on the fulfilhnent server 84 each time an incoming 
message is written to the inbound queue on this server. Fulfillment pipeline object 87 
extracts the logging information fi-om each MSMQ message and write it to logging 

20 database 91, where it may later be used by reporting scripts. Additionally, fulfillment 
pipeline object 87 will be triggered by changes in the fulfillment database 89 and will 
push any update/delete information to the various MSMQ independent clients 86 hosted 
on the download servers 76. 

Content management tool 82 is responsible for managing the information 

25 stored in the fulfillment database 89. When LIT files are added to the content store 80, 
this tool writes the appropriate fields into the fulfilhnent database 89 (e.g., the Book ID 
to physical location mapping) such that content store plug-in module 88 may later find 
the requested LIT files. Similarly, if any changes are made (e.g., a change the DRM level 
on a LIT file) this tool provides the interface fi-om which those responsible for the 

30 content management function inside the fiilfillment center (i.e., human content 
administrators) would carry out these tasks. 
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Fulfillment centers 73 may accomplish the task of content management 
by building a set of ASP pages that, via standard IIS COM objects, write all the relevant 
information into the fulfillment database 89 and place the incoming LIT file (already 
encrypted as a source sealed copy) into a staging server 83, which would mimic the 
5 directory structure of the production content store 80. From there, LIT files would be 
automatically replicated using, e.g.. Site Server 2000 Content Replication Server, into 
the production content store server. Staging server 83 is not necessarily required to 
implement the DAS system, but it is an advantageous approach to replicate LIT files 
from the network of the fiilfillment partner into the production content store servers by 

1 0 using tools such as MICROSOFT® content replication server (CRS). 

The activation servers 94 perform the function of providing each client 
reader (e.g., PC reader 90 or dedicated reading device 92) with a unique secure 
repository and an activation certificate. An exemplary secure repository, and systems and 
methods for providing same, are disclosed in Attorney's Docket No. MSFT-0126, filed 

1 5 concurrently herewith, which is expressly incorporated herein by reference in its entirety. 
The secure repository and activation certificate associates the activated reader with an 
online persona (e.g., a MICROSOFT® PASSPORT™ ID) to ensure that users will be 
able read their rightfully acquired titles on all instances of readers that they own or have 
activated to their persona (but not on non-activated readers, or readers not activated for 

20 that persona) - assuming they activate their readers using the same user ID and password 
every time. 

Activation Server 94 includes a PASSPORT object 96 and an activation 
server ISAPI Extension DLL 98. The PASSPORT object 96 provides the required 
interfaces into the PASSPORT^*^ servers that authenticate the end-users using, for 

25 example, their hotmail accounts (or other PASSPORT credentials). In accordance with 
aspects of the present invention, this object advantageously associates the activation 
certificate with a persona, instead of a single PC, thus allowing each persona to utilize 
multiple readers to read level 5 titles. While it will be appreciated that tying level 5 tities 
to a "persona" permits wider use of level 5 tities than if they were bound to a single 

30 device, defining a persona in terms of an established namespace authority such as 
PASSPORT servers is also serves the goal of limiting the xmrestrained use of level 5 
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titles that might otherwise exist if users were permitted to use an arbitrary label to 
function as a persona. In the case of PASSPORT credentials, personal information 
relating to a particular user is associated with that user's PASSPORT credentials, 
possibly ranging from the user's E-mail accoimt to his credit card number. Thus, a user is 
5 unlikely to share his PASSPORT ID and password with a large group of people, thereby 
ensuring that the persona to which a reader is activated is genuinely associated with a 
particular user (or, possibly, a family that shares a single PASSPORT account). While a 
PASSPORT server is an exemplary namespace authority that can provide this 
advantageous feature, it will be appreciated that other namespace authorities could be 

1 0 used without departing from the spirit and scope of the invention. In such an altemative 
embodiment, PASSPORT object 96 would be replaced with a different object which 
communicates with the altemative namespace authority. 

The activation server ISAPI Extension DLL 98 carries out tasks 
associated with the activation process on the ftont-end activation servers, including 

1 5 receiving a hardware ID uploaded by the reader client, creating a unique machine ID 
based on the hardware ID, posting a request to the secure repository server(s) 100, 
signing each unique secure repository received from secure repository server(s) 100, 
generating and (optionally) encrypting the activation certificate, updating activation 
database 102, and downloading both the secure repository and the activation certificate 

20 to the reader client. The activation process is more particularly described below in 
connection with FIG. 8. 

The secure repository servers 100 are preferably stand-alone servers 
located behind a firewall in a data center. They are accessed by the activation servers 94 
for generating individualized secure repositories for each reader being activated. These 

25 servers are preferably dedicated, and preferably run a WINDOWS® 2000 or WINDOWS 
NT® service that exposes a socket interface to activation servers 94. The secure 
repository service links a distinct executable for every unique machine ID and passport 
ID combination posted. The task of preparing an individualized secure repository is, in 
many cases, computationally intensive. Therefore, in a preferred embodiment there is a 

30 sufficient number of secure repository servers 100 to provide secure repositories to 
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readers in real-time (e.g., a few seconds per activation), taking into account the expected 
volume of activation traffic. 

The activation database 102 is preferably a MICROSOFT® SQL 7.0- 
based server that stores activation information related to each end-user of the reader 90 
or 92 (based on their PASSPORT^'^ IDs). Such information may include: Machine IDs, 
the number of activated readers, the date of first activation, the product ID (PID) for each 
of the reader installations, their PASSPORT^'^ profile info, etc. This information is used 
to ensure that users are not abusing the system, helping users recover fi-om hard-drive 
crashes, and aiding in allowing users to continue reading the content they purchased after 
a hardware upgrade. For example, the nimiber of activated readers and the date of the 
first activation associated with a particular PASSPORT credential could be used to 
impose a limit on the number of activations (e.g., no more than five activations for a 
given persona in the first 90 days following the first activation, with an additional 
activation permitted each 90 days thereafter, up to a total of 10 activations). Imposing 
such a limit (or some other type of Umit) has the effect of preventing the unchecked 
proliferation of readers activated to a single persona (which, in the worse case, could 
result in a level 5 title being readable on millions of reading devices, thereby thwarting 
the goal of controlling distribution of valuable content). Additionally, the other 
information in activation database 102 enables users to use level 5 titles after a hardware 
upgrade (or after a hard disk crash), without having to re-download titles or licenses. In 
this instance, all a user needs to do is to activate the reader on the upgraded (or repaired) 
hardware with the same PASSPORT™ ID. 

Activation database server 102 is preferably located behind a firewall and 
is only accessible by the fi:ont-end activation IIS servers on the same private network 
where the secure repository servers are located. A replica of activation database 102 may 
be accessed via offline scripts to generate reports of the number of activations per day, 
week, month, average of activations per PASSPORT™ ID, etc. 

Receipt Infrastructure 

As described briefly above, the server architecture of the present 
invention includes a URL encryption object 74, which encrypts certain parameters 
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relating to the sale of an eBook 10, where the encrypted parameters are includable in a 
URL. The following is a more detailed overview of the use of URL encryption object 74. 

URL encryption object 74 facilitates a decoupling of the seller of eBooks 
(e.g., the retailer) from the entity that actually provides the LIT file to the purchaser (e.g., 
5 a fulfillment center). The URL encryption object 74 performs this function by encrypting 
information relating to the purchased eBook with a secret (e.g., symmetric key 75), 
which is shared between the fulfillment center and the retailer. In an exemplary scenario, 
the retailer enters into a business relationship (e.g., a contract) with a fulfilhnent center, 
whereby the fulfilhnent center agrees to provide content dowmload services for the 

10 retailer who does not actually have an electronic stock of eBooks or the server devices 
needed to download eBooks to a large number of purchasers. As part of this relationship, 
the retailer and fulfilhnent center agree on a secret symmetric key 75, which will be used 
by URL encryption object 74 on the retailer site, and by ISAPI extension DLL 78 on the 
fulfillment center site. Essentially, the retailer uses the URL encryption object 74 and the 

1 5 secret symmetric key 74 to encrypt information relating to the purchase of an eBook, and 
includes this encrypted information as a parameter to a URL that points to the fulfilhnent 
center site. The URL is then rendered on the purchaser's browsing software as a "receipt 
page," where the "receipt" is a hyperlink to the URL that invokes the download from the 
fulfilhnent center. When the user follows the link, the fulfilhnent center receives the 

20 encrypted parameter and decrypts it using shared secret symmetric key 75. Because the 
parameter is encrypted, any secret information that needs to be exchanged between 
retailer and the fulfilhnent site can safely be provided in encrypted form to the 
purchaser's site, since the purchaser does not know the symmetric key 75 (and, 
presumably, other lurking eyes on the web also do not have access to symmetric key 75). 

25 Moreover, when the fulfilhnent center decrypts the encrypted information to obtain the 
information necessary for the download, proper decryption of the information 
authenticates the "receipt" as having been generated by a legitimate retailer, since 
presumably no one other than the retailer has the symmetric key 75 necessary to properly 
create the encrypted parameter. It should be noted that symmetric key 75 is merely 

30 exemplary of the type of secret that could be shared between a retailer and a fulfillment 
center to permit this manner of communication. In an alternative embodiment, 



wo 01/44907 



PCT/USOO/33726 



-23- 

asjmMnetric key pairs could be used, or the retailer and fulfillment center could agree on 
a secret keyless encryption method. 

FIG. 5 depicts the use of URL encryption object 74 to create the 
encrypted parameter. URL encryption object 74 encrypts the URL parameter using a 
5 symmetric key 75 (the URL "secret") that is shared between the download server ISAPI 
78 and the URL encryption object 74 on the retail server. In a hosted scenario, where a 
fulfillment center provides for the download of LIT files sold by a large number of retail 
sites, a symmetric key 75 is provided to each retailer as they enter into a contract with 
the fulfillment center 73. It is important to note that this symmetric key 75 can be unique 

10 per retailer 71 . Fulfilhnent center 73 may store the keys for each retailer in fulfilhnent 
database 89. It should be noted that symmetric key 75 used for encryption of the URL 
parameter is different firom the synrunetric keys 14A generated by the content 
management and encryption tool 82 to encrypt the LIT files. 

A single exported method on the URL encryption object 74 ("EncryptQ")* 

15 creates the encrypted URL parameters. Preferably, the EncryptQ method takes the 

following parameters to be incorporated into the encrypted blob that will be used in the 
URL: 

TransactionID - a string that uniquely identifies each transaction on the 
bookstore site 72; 

20 BookID - a unique identifier, which is used by download server 76 to 

locate the proper LIT file via content store plug-in module 88 (which looks-up the 

BookID in fiilfilhnent database 84); 

BooklDType - identifies which type the ID is (e.g. ISBN, DOI, PATH, 

etc.). URL encryption object 74 preferably does not validate this field, or its relationship 
25 to the ID. Download server ISAPI 78 later uses this field as an additional input parameter 

to the lookup performed by the content store plug-in module 88; 

UserName - a string containing the name of the rightful owner of the 

eBook purchased. This string preferably maps to the consumer listed in the credit card 

used for the commercial transaction, although this is left as policy to be set by the 
30 content source (e.g. the publisher) in accordance with the fulfilhnent center. This string 

is the name that will later by used by the Download Server ISAPI 78 to individually seal 
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the titles (i.e. to generate the Bookplate). It will be recalled that individualized titles (e.g., 
level 3 and level 5) incorporate the user's name into the LIT file and bind that name to 
the decryption key, so that the origin of unauthorized distribution of content can be 
detected. Therefore, it is preferably that the purchaser's name come from a reliable 
source (such as the user's credit card), rather than from an unverifiable source (such as 
user input). Although the foregoing example assumes that a name will be inserted into 
this field, the actual contents of the field is determined by the retailer, and it could 

contain any information (e.g., credit card number, transaction ID, receipt ID, etc.) - 

* 

preferably information that relates to the purchase or purchaser so as to permit 
surveillance and tracking of the copy; 

PASSPORT ID - The persona ID associated with the user, which is 
provided by the user during activation. This field is later used by the content server to 
compare with the activation ID in the activation certificate. It should be noted that, while 
the PASSPORT ID is contained in the activation certificate, that ED is not uploaded to 
bookstore server 72 during the purchase transaction. Rather, the activation process, in 
addition to inserting the PASSPORT ID into the activation certificate, also stores the 
PASSPORT ID in the registry on the user's computing device, and it is the registry 
instance of the PASSPORT ID that is provided to bookstore server 72; and 

SecurityLevel - this string indicates what level of DRM this particular 
publication requires. This will later be converted into a nimiber and stamped into the 
title's meta-data 12 by the download server IS API 78; 

Optionally, the following input parameters may also be included with a 

request: 

Cost - the price that the merchant (i.e., retailer 71) paid for that eBook 
title at the moment the tile was sold to the consumer; 

MSRP - recommended price from the pubUsher at the moment the tile 

was sold; 

Price - the price by which the eBook title was sold. This is an optional 
parameter, and if present will be used by the download server for logging purposes and, 
potentially, for biUing purposes; 
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FriendlyFileName - this string is used by the download server when 
setting the filename for the LIT file being downloaded via the response HTTP header; 
and 

CustomerlD - a unique identifier for the end-user purchasing the eBook 
5 title. The merchant (i.e., retailer 71) may require this information as part of the reports it 
receives from the fulfilhnent center. 

The above parameter list is extensible and should not be interpreted as 
limiting or the fiiU set supported by the URL encryption object 74. Additional attribute- 
value pairs may be added, since the URL encryption object 74 will encrypt the whole set 
10 of values passed and retiuns them to the calling fimction. 

Preferably, the URL encryption object 74 adds a timestamp and version. 
The timestamp is string which preferably contains a representation of the number of 
nanoseconds passed since 1601 (in GMT system time) on the local machine where the 
URL encryption object 74 is installed. This value may be used by the download server to 
15 calculate a time-to- live (TTL) in order to avoid playback attacks (i.e., someone stealing a 
URL and playing it back to download a book. The version field is an unencrypted string 
identifying the version of the URL encryption object 74 that created the encrypted blob 
in the URL. 

After the retailer 71 obtains the encrypted string back from the URL 
20 encryption object 74, the retailer 71 builds a POST request that points to the download 
server 76 for fiilfillment. The encrypted blob returned by the URL encryption object 74 
is included in the body of each POST. In addition to the encrypted parameters, retailers 
may need to provide a RetailerlD in the URL which identifies the retailer. This may be 
used by the download server IS API DLL 78 to map the incoming request to the 
25 appropriate URL symmetric key 75 for decryption in the case where multiple retailers 
are being supported by a single download server site 76. This is an optional field and if 
not provided, the download server ISAPI DLL 78 at the fiilfilbnent site 73 will later use 
its default symmetric key 75 provided during setup for decrypting the URLs. 

Therefore, in accordance with the above, assuming an input to the URL 
30 encryption object 74 such as: 



i 
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TransactionId-R6RAKHAL9TS12n'G00QP9ESTQ4&BookId=044021145X&BookIdT 
ype=ISBN&Usemaine=Pavel+Zeman&SecurityLevel=3 

The Encryption COM object 74 may return the following encrypted blob: 
LCfsQCLuMg9UZtWxIdYTfw%2B2MtjXAN%2BiU0YHaomrY3ydXhw3p9Tl^^ 
5 2BFEHTEP687Nql7wbMMwnbtHAkIjkKhKS%2BYKwgHj7%2FNr%2BvBD 

MbvN3saNBrPxG8slziUliX%2F%2BSS%2FttA%2F4GZjRMo5uXWM%2BZr5dYHk 
SfWfBBC0iH7uLFolyl28LSI=&Version=1.0 

The URL encryption object 74 URL encodes the encrypted blob, such that 
it complies with the required HTTP standard for ANSI URLs. The URL encryption 

10 object 74 accepts both Unicode and UTF-8 strings, and handles UTF-8 conversion from 
Unicode internally. Optionally, the URL encryption object 74 use UTF-8, if provided, 
which reduces the size of the resulting encrypted end escaped blob for non-Unicode 
input by approximately one-half The URL encryption object 74 preferably computes a 
cryptographic hash of the data to be encrypted prior to encrypting such data, and includes 

15 the hash with (e.g., in front of) the encrypted and encoded data. This hash may later be 
used for comparison by the download server to verify that the decrypted data has not 
been tampered with between the retail site and the download server. For example, the full 
parameter (e.g., to be included in the body of a POST request), may read: 

VALUE="&Hash=bCt/xn41frjw7cPQjstge+6Lifc=&Data=zAybPKW123 

20 d20+...encoded_data_continues...MSSD8Eyw=&Version^L5" 

The download server ISAPI 78 is responsible for the individualization and 
download of eBook titles to end-users. Also, parsing and validation of each URL 
generated by the URL encryption object 74 is performed by the download server ISAPI 
DLL 78. This includes decrypting the URL using the appropriate symmetric key 75, 

25 which can be either a default key or, in the case where a retailer ID is provided, a string 
resulting from a database lookup via the content store plug-in module. The download 
server ISAPI DLL 78 also resolves the mapping of Book ID and Book ID Type from the 
passed URL into a file share location preferably via a plug-in module. The plug-in 
module retrieves that information from the fulfillment database and enables content 

30 providers to add their own mapping database and naming convention rules. 
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The download server IS API 78 also determines the DRM protection level 
required for the download of the requested LIT file. The level will be determined based 
on an indication from the fulfillment database 89 of the DRM Level for the title being 
downloaded. For example, if the URL created by the retailer defines a DRM level lower 
5 than that specified in the fulfillment database, an error message will be returned to the 
Retailer 71 . Also, the IS API will fetch the eBook title for download from the content 
store 80 into a local memory cache, if not cached, strip the symmetric key 14A (see FIG. 
1) from the LIT file prior to caching it locally on the IIS server, and cache the key 14Ain 
memory for fiiture use. 

10 In the case of DRM level 3 titles, the dovmload server IS API 78 inserts 

the user's name from the URL encrypted blob into the LIT file as a separate stream, re- 
hashes the meta-data with the contents of this new stream, seals the symmetric key 14A 
with the newly computed cryptographic , hash, and re-insert the newly sealed symmetric 
key into the LIT file for download. In the case of DRM level 5 titles, the download 

15 server IS API generates a license XML structure (in addition to the level 3 actions noted 
above), seals the symmetric key with the pubUc key from the end-user's activation 
certificate, and embeds the license in the LIT file. 

The download server ISAPI 78 also downloads the LIT file to the end- 
user, releases the temporary storage used during individualization of the LIT file, and 

20 logs each download request into either a local file on the IIS server or to the logging 
database 91, via the asynchronous fulfillment pipeline discussed below. This may be 
performed via a message post to the local MSMQ client resident on each Download 
Server 76, 

The download server ISAPI extension DLL 78 responds to a set of 
25 commands defined by the "?action=" parameter. Preferably, there are two actions 

supported by the download server ISAPI 78: download and verify. The download action 
is the conunand that causes the ISAPI 78 to follow the steps identified in FIG. 7 and 
return an eBook title to the user. The verify action is used to request the ISAPI 78 to 
verify that a given BookID exists in the content store 80 and is ready for download. The 
30 most common command (download) may look Hke the following URL: 
http://content-provider.com/isapi/ds.dll?action=dovmload&value=. . . 
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The /isapi/ parameter in the URL indicates the virtual root where the 
ISAPI 78 was installed. In this example the ISAPI 78 is called ds.dll (Download Server 
DLL). The name of ISAPI 78 is followed by the action, which is followed by the 
relevant parameters to carry out that action (the "value" parameter in the above 
5 example). In this examples, the relevant parameters comprise the encrypted blob 
generated by the URL Encryption COM object 74. 

Each download request will include, in the body of the POST, the URL 
for the error-handling page on the retailer site 71 . The download server 76 uses this URL 
whenever an error occurs and redirects the client to that page, with the error code tagged 
10 in the query string. In the event of an error, the retailers may provide an HTML UI, a 
support number, an e-mail link, or trouble-shooting instructions. In accordance with an 
aspect of the present invention, the download server ISAPI DLL 78 preferably does not 
render errors, but rather, redirects the users to the required error handling URL from the 
POST request. 

15 From a data-center management and operability standpoints, the ISAPI 78 

will expose performance coxmters (i.e., PerfMon counters) and WINDOWS NT® events. 
These are typical WINDOWS® 2000 and WINDOWS NT® operational practices for 
data-center deployment and management of server components. WINDOWS® 2000 and 
WINDOWS NT® events are logged whenever an error occurs. Some of the key events 

20 that are preferably logged by the ISAPI 78 are: 

Failure to Initialize - any missing configuration and/or required 
environment setting that caused the ISAPI to fail on load; 

Failure to Connect to the Content Store - either the UNC path returned by 
the content store plug-in module was invalid or the content store 80 and/or network path 

25 to it is down. In either case, the ISAPI must log an error such that data center operators 
can take proper action; 

Illegal URL Request - this event must be logged whenever a URL request 
does not comply with the expected format or has not been encrypted by the symmetric 
key 75 shared between the ISAPI 78 and the URL COM Object 74. Ideally, the full 

30 URL should be posted on the event, along with the originating IP, for audit purposes; 
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Failure to locate a LIT file - either the path on the request was invalid or 
the LIT file is missing fi-om the target share; 

Failure to cache LIT file - this can happen if the content server 76 hosting 
the ISAPI 78 runs out of memory, or if a network problem occurred during file 
5 transmission fi-om the Content Store 80; 

Failure to create Bookplate - this event must be logged anytime the ISAPI 
78 is unable to carry out the individual sealing of the title. The nature of the error must 
be included on the event itself, for later debugging; 

Failure to download title - this event must be logged whenever a 
10 download fails (time-out, connection broken, etc.); and 

Startup/Shutdown events - whenever the ISAPI 78 is (un)loaded, it must 
log an infonnational event to this extent, such that proper visibility exists. There may be 
cases when an ISAPI 78 is unloaded by IIS and data center operators need to re-start IIS 
or even WINDOWS NT® to get the content server 76 back into a fiilly operational state. 
1 5 The Download Server ISAPI 78 also preferably expose the following 

Performance Counters: 

Total download requests - measured in unique requests accepted since 
last startup of the server; 

Total successfiil downloads - measured in unique requests fiilfilled since 
20 last startup of the server; 

Download requests/sec - number of unique incoming requests/sec; 

Successfiil downloads/sec - measured in unique requests fiilfilled per 

second; 

Pending download requests - total number of requests being processed at 
25 any given time; 

Failed download requests - total number of failures since last startup of 

the server; 

Average request processing time - measured in milliseconds, it reflects 
the average time the ISAPI is taking to process incoming requests; and 
30 Last request processing time - measured in milliseconds, it reflects the 

time it took for the ISAPI to process its most recent request; 
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Combined, the WINDOWS NT® events and PerfMon counters will allow 
a host of existing data center monitoring and management suites to administer the IS API 
78 during the deployment of the system. 

Asynchronous Fulfilknent Pipeline 
5 The Asynchronous Fulfilbnent Pipeline performs asynchronous logging 

of download requests into the logging database 91 and asynchronous invalidations of 
cached entries by the download servers ISAPI DLL. The asynchronous fulfillment 
pipeline server accomplishes these tasks by leveraging the existing store-and-forward 
functionality provided by the MICROSOFT® Message Queue (MSMQ) component of 

10 Windows® 2000. 

The architecture for the fulfillment pipeline is show in FIGS. 4 and 6. The 
fiilfilhnent pipeline objfect 87 is executed by the MSMQ trigger service and writes to the 
logging database each time an incoming message appears in the inbound queue of the 
local MSMQ client 86. Preferably, fulfilbnent pipeline object 87 is implemented as a 

15 COM object. The cache update agent 85 has an associated executable that is spawned by 
a SQL trigger anytime an update or a delete operation occur on the fulfillment database 
89. The download server ISAPI extension DLL 78 will both read and write to/from the 
local MSMQ independent client 86. 

A logging function preferably runs on the logging database 91 to persist 

20 all parameters that are passed on the body of each POST request for downloads. The 
fiilfilhnent pipeline COM object 87 is instantiated on the fulfillment server 84 as each 
individual logging message arrives in the inbound queue of the local MSMQ 
independent client 86 on the fixlfilhnent server 84. The logging database 91 schema is 
described in further detail below. The information from the body of each POST request 

25 to the download servers 76 is converted into a MSMQ message format and posted to the 
inbound queue of the local MSMQ client 86 on the fiilfillment server 84. 

The MSMQ client 86 on the fulfilhnent server 76 then picks up this 
message packet and invokes, via the MSMQ triggers service, the fulfillment pipeline 
COM object 87, which converts the message to database format and writes it in the 

30 database, via a Data Source Name (DSN) on the fulfillment server 84 that abstracts the 
name, location, and login credentials for the logging database from the COM object. 
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As the content management tool 82 updates and/or deletes records from 
the fulfilhnent database 89, a cache update agent executable 85 is triggered by the SQL 
server (using standard SQL update/delete triggers). Cache update agent 85 performs a 
similar function to the fiilfilteient pipeline COM object 87, but in the opposite direction. 
5 Given that update and delete operations to the fulfillment database 89 may require cache 
updates to the front-end download server ISAPI DLLs 78, this agent will form a MSMQ 
message and post it through the independent MSMQ client 86 to all the download 
servers 76 (the fulfillment server 84 should have a list of all installed download servers 
76). 

10 On receiving the cache update message, the MSMQ client 86 on the 

download server 76 calls a function on the ISAPI extension DLL 78 to update the cache. 
This action removes the cache entry. The next time a request is received for this 
particular Book ID, the download server 76 will again query the fulfillment database 84 
and then update the cache with the new LIT file and its relevant attributes. The size of 

15 the cache for the download server 76 is determined by the amount of free memory on the 
physical server. It is preferable that the ISAPI DLL 78 allocate up to 80% of the 
available memory on the server. 

License Generation 

Licenses are preferably generated for all signed and fiilly individualized 
20 titles (i.e., level 5). The source publication may also be accompanied by a license that 
constitutes the source signature, thus ensuring authenticity of the eBook being purchased 
by the consxmier. Licenses can be delegated and the license chain preferably originates at 
the publication providers (i.e., authors and publishers) and ends at the buying consumer. 
In accordance with the present invention, rights may preferably be delegated by licensors 
25 but not by consumers. An end-user license is typically generated at the time of 

download. In some cases, the retailer will name the rightful owner of the eBook (in the 
case of individually sealing) in the license, which is later exposed via the UI (by a feature 
of the reader 90 or 92) when consumers open their eBooks. 

Referring now to FIGS. 4 and 7, there is illustrated the process flow of 
30 license generation process. At step 110, the process begins and the request (e.g., the 
request embodied in the encrypted URL blob) is parsed for attributes (step 1 12). If the 
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request is well formed at step 1 14, then it is determined if the request is for a level 5 

license (step 118). If not, then at step 116, an error is returned and the process is halted. 

If at step 118 it is determined that the request is for a level 5 hcense, then 

it is determined at step 120 if the user principles were provided. If they were provided, 

5 then the principles are persisted in a local database at step 130. If not, then at step 122, it 

is determined if the user principles can be retrieved from a local database. If not, then 

they are fetched from the registration server at step 124, and if successful (step 126), the 

data is persisted in the local database at step 130. If the request to fetch the data from the 

registration server failed at step 126, then an event is logged (step 128) and the process 

10 ends at step 146. 
« 

If at step 122, the user principles can be retrieved from the local database, 
then processing continues at step 132, where the symmetric key is encrypted with the 
user's public key from the certificate. Step 132 is also performed after the user principles 
are persisted in the local database at step 130. Processing then proceeds to step 134, 

15 where it is determined if the license is individualized. Step 134 is also where processing 
continues if at step 1 18 it is determined that the request is not for a level 5 license. 

If at step 134 the license is individualized, the user's name is included in 
the license as the rightful owner. Processing continues at step 136 where the license 
XML structure is completed with the user's name and signed. If at step 134, the license 

20 is not individualized, process then continues at step 138 where the license XML structure 
is completed (without the user's name) and signed. At step 140 it is determined if the 
license generation succeeded. If so, then performance counters are updated and the 
license XML file is returned (step 144), and, if not, an event is logged and error returned 
(step 142). Processing then completes at step 146. 

25 Once a download is started at the fulfillment center 73 (i.e., users have 

placed an order and then clicked on the link to download), in the case of a fully 
individualized title the download server ISAPI DLL 78 preferably posts a request to the 
licensing module 77 to generate a unique license for the eBook title being downloaded. 
The download request URL must provide, as part of the encrypted parameters, 

30 information such that the license module can individually seal each license. These 

parameters include, for level 5 copies, the encrypted activation certificate downloaded to 
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the end-user during activation of their reader software. A licensed eBook cannot be 
opened unless the required license is present and available to the reader. 

After users purchase their eBook devices or download the reader software 
90, 92 from the Internet, they will be encouraged to activate their readers the first time it 
is launched (e.g., inmiediately after setup for the laptop/desktop reader ^plication). 
Activation enables the reader software for the purchase of fully individualized, level 5 
protected copies. The process-flow of reader activation, the end-user experience, and the 
client-server interactions that take place wilt now be described. 

Each time reader 90 or 92 is launched, it checks to see whether it has been 
activated. If not, the reader will render a dialog box reminding the user that they will not 
be able to acquire premium titles that require full individuaUzation for distribution unless 
the user activates the reader. Users may activate the reader from any retail web site, 
while shopping with a stand-alone browser, or from within an "integrated bookstore" 
feature of the reader (which permits communication with bookstore sites using the reader 
software itself instead of general-purpose browsing software). Still further, the reader 
may be activated from within a merchant's site, while shopping inside the integrated 
bookstore feature of the reader. This activation scenario may occur if, for example, the 
user declined to activate the reader during first launch and now wants to purchase a fully 
individualized (level 5 protected) title, which requires activation. 

Assuming the user has agreed to activate the reader as above, the process 
that follows will include the following steps, as illustrated with respect to FIGS. 4 and 8. 

At step 150, the reader client opens into the integrated bookstore feature 
and connects, via secure sockets layer (SSL), to the activation servers 94, where users are 
prompted to login using, in this example, their PASSPORT™ credentials (step 152), If 
the user does not have a PASSPORT^'^ account, he/she will be provided with at link to 
sign-up for one (step 154). It is preferable that the URL to the activation server 94 be 
hard-coded into an Activation ActiveX control using a SSL connection such that the 
cHent can guarantee that the servers are truly the activation servers 94. 

Once user's PASSPORT™ credentials are authenticated (step 156), a 
PASSPORT™ API is queried for the user alias and e-mail address (step 158). Thereafter, 
at steps 160-162, the activation servers 94 will request that the client (via the ActiveX 
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control) upload a unique hardware ED (e.g., which, as noted above, may be derived from 
hardware components on the user's computing device which substantially uniquely 
identify the user's computing device). Next, it is determined at step 164 if this is a new 
activation for the reader (as opposed to a "recovery" of a prior activation). 

If it is determined that this is a new activation at step 164, then the 
process proceeds to step 168 to determine whether an activation limit has been reached. 
If the limit has been reached, then an error message is rendered at step 172, preferably 
including a support telephone number. The process then ends at step 198. In accordance 
with a feature of the present invention, users may be limited as to the number of 
activations they can perform, and/or the rate at which they can perform them (i.e., how 
many different readers they can activate to read level 5 titles purchased imder a given 
persona). In the example of Fig. 8, users are limited to five activations within 90 days 
after the first activation of the reader. This allows the users to active their own readers, 
while preventing abuses of the DAS System. An example of the type of abuse that such a 
limit prevents would be a book club's purchasing an eBook with its PASSPORT account 
and permitting thousands of its members to activate their readers with the book club's 
PASSPORT credentials. The limit on activations may also allow for additional 
activations as time passes - e.g., one additional activation for each 90 day period after 
the first 90 days, up to a limit of 10 total activations. It will be appreciated that these 
limits are merely exemplary, and any limit on activations may be used without departing 
from the spirit and scope of the invention. 

If the user has not activated over five readers within the first 90 days (or 
reached a different appUcable activation limit), an activation page is rendered on the 
user's device (step 170). When the user returns the form, the activation servers determine 
whether the form is complete (step 174); if the form is not complete, the process returns 
to step 170 to re-render the form until the user completes the form. Next, at step 176, it is 
determined if this activation is a recovery. If it is not a recovery, then a new record is 
created for the user and reader and the number of readers activated to that user is 
incremented (step 180). A pre-generated secure repository key pair is retrieved from a 
database (step 182) and activation certificates are also generated (step 184). The 
activation keys, user ID, and machine ID are persisted in a database at step 186. In one 
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example, each user (i.e., persona, as identified by, e.g., PASSPORT account) is assigned 
an activation key pair which is used in the activation certificate for every reader that user 
activates, in which case the symmetric key 14A of level 5 titles is encrypted with the 
public key in the activation key pair at the time the title is prepared for that user by 
5 fulfillment site 73. In a further refinement of that example, each reading device is 
equipped with a unique, individualized secure repository that has a unique key pair 
associated therewith, where the activation certificate for a given device contains its 
private key in a form encrypted by the public key associated with the secure repository. 
In this way, in order to render a level 5 title it is necessary for both the secure repository 

10 and the activation certificate to be present, since the secure repository uses its private key 
to decrypt the private key of the activation certificate, which, in turn, is then used to 
decrypt the symmetric key 14A of the eBook title, which, in tum, is used to decrypt the 
content stream 16 of the eBook title. Processing continues at step 188. 

If, at step 176, it is detemiined that this activation is a recovery, then (at 

15 step 178) activation certificates are generated with the information that was stored at step 
186, and processing continues at step 188. 

At step 188, the activation servers generate and digitally sign an 
individualized secure repository executable (tied to the uploaded machine ID) and an 
activation certificate (tied to the user's PASSPORT™ ID). The secure repository 

20 executable and activation certificate are then downloaded to the client (steps 188 and 

190). The activation certificate is encrypted (for privacy reasons) and is later uploaded by 
the client to the download server for preparing fiiUy individualized copies (level 5 
protected titles). The user^s PASSPORT™ ID may be encrypted and stamped in the PC 
Registry as part of this download, for upload during commercial transactions. This 

25 procedure may ensure that the PASSPORT™ ID included in the URL for download 
matches that of the activation certificate that's included in the body of the Post, to avoid 
theft of content. 

At step 192 it is determined if the download was successful. If not, an 
event is logged and the download is attempted again (steps 194 and 192). If the 
30 download was successful, then at step 196, the user is provided with a "congratulations 
page" and is informed that activation is complete. The "congratulations page" may also 
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provided a link to redeem promotional free books at this time, as a way to encourage 
users to activate their readers. This link may leverage a method exposed by the 
Activation ActiveX Control to return the user to a library page on the reader. The process 
then ends at step 198. 

5 It is preferable that once the reader coimects to the activation servers 94, 

that the servers 94 drive the entire user experience via ASP and HTML pages. These 
pages preferably conform to standard specification, and will use the style guide and Java 
script methods provided to ensure a seamless experience this is consistent with the "look 
and feel" of the reader user interface. 

Part of the activation process for the open platform reader (e.g., a reader 
software application installed on a PC) is the secure repository individualization and 
subsequent download. As discussed in greater detail in Attorney's Docket No. MSFT- 
0126, filed concurrently herewith and incorporated herein by reference in its entirety, 
there is provided a server component (e.g., secure repository server 100, shown in FIG. 
4) that is responsible for individualizing secure repository software modules to each 
instance of the reader for open platforms (e.g., laptop and desktop computers). The 
unique secure repository hides cryptographic keys used in the process of xmsealing and 
decrypting level 5 LIT files, as well as ensuring that decrypted level 5 content does not 
escape from the controlled system, and, because it is individualized for a particular 
hardware installation, it resists portability and, should it be broken, its individualization 
resists using the same breaking techniques on a different secure repository installed on 
different hardware. 

As noted above, one aspect of resisting abuse of the DRM System is to 
limit the number of activations that any particular user may have with a single 
PASSPORT™ ID. If this number is not limited, dishonest users may be able sign-up for 
a "public domain" PASSPORT™ then share the credentials for that account with all of 
their fiiends (or worse, post it on the Web), along with all eBooks they purchased. This 
will quickly create a piracy chain, since any user who activates the reader with the 
"public domain" PASSPORT credentials could then read level 5 titles individualized for 
that "public domain" account. 
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Therefore, in accordance with a feature of the invention, it is desirable to 
have activation "quotas" that allow users to activate readers on multiple devices that they 
own (e.g., a laptop, desktop, PocketPC, eBook, etc.) as well as allow them to activate 
new devices as they upgrade their hardware, reformat their hard disks, etc., without 
5 permitting unchecked and unlimited activations of readers to the same PASSPORT 

credentials. Past experience with user behavior suggests that legitimate users activate one 
reader (or a small number of readers) initially, and then may activate new readers 
occasionally but are not likely to activate new readers as often as every day or every 
week. To enable these legitimate uses of the activation system, while preventing abuse, 

10 the number of activations for a given user (a Passport™ ID) will be periodically 

increased, up to a defined maximum (which will be, e.g., five activations initially). As 
the user activates new devices, his quota of available activations goes down. As time 
passes, the number is increased, at a suggested rate of, e.g., one additional activation 
every 90 days (from the date of the first Activation) until the number reaches 10. This 

1 5 type of limit will allow users to activate readers (or reactivate, say, old readers on 

devices with reformatted hard disks) with a reasonable frequency, and will resist abuse 
of the system by "pirates." 

The activation servers 94 enforce the limit on activations by storing, in the 
activation database 102, a list of all activations that a given PASSPORT™ ID has 

20 requested, along with their date stamps. If a re-activation request is made, the quota is 
not affected, so long as the machine ID (e.g., the unique number that ties the secure 
repository to the hardware hosting the reader) is the same (since this would not result in 
theft, as the same PC is being activated again). 
eCommerce Process Flow 

25 An overview of the basic process by which eBook titles are acquired and 

delivered online is now described with reference to FIG. 9. Using a browser or the 
"bookstore pages" or reader 90 or 92, user chooses book(s) via mechanisms that the 
retail site implements (step 200). The user then pays for the titles, if payment is required 
(step 202). The transaction concludes at step 204 with a receipt page (i.e., an order 

30 confirmation or "thank you" page) that contains links (POST requests) for downloading 
each title purchased (i.e., the URLs containing the address of content server 76, plus the 
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encrypted information created by URL encryption object 74). For fully individualized 
copies (level 5), a client-side script will populate the body of the POST with the 
activation certificate, preferably using COM object implemented by the reader which 
obtains the necessary activation certificate or relevant information therefi*om. 
5 Upon cUcking on any of the links at step 206, the browser initiates a 

download firom content servers 76 (via the download server ISAPI DLL 78). For 
individually sealed (bookplate (e.g., level 3)) copies, the download server 76 adds the 
consumer's name to the title meta-data and re-seal the symmetric key 14A using a new 
cryptographic hash resulting fi'om the new meta-data, which now includes the user's 

10 name. For fiiUy individualized copies (level 5) a license is generated and embedded in 
the LIT file, in addition to the Bookplate being created. This license contains the 
symmetric key 14A that encrypted the LIT file "sealed" with the public key in the 
activation certificate. When the download is complete (step 208), the download server 76 
logs the transaction and, on the client, the reader is launched automatically (step 210). 

15 The title may be moved into a "My Library" folder (e.g., on a PC using one of the 
MICROSOFT WINDOWS operating systems, such a folder might be called 
C:\MyLibrary, and would be reserved for the storage of LIT files). The eBook is opened 
to its cover page and the rightful owner's name is rendered under the author's name. 

The eCommerce process is fiuther detailed in Fig. 10 with specific 

20 reference to the components of the DAS system. At step 1, the client 90 or 92 makes a 
POST request to the download server ISAPI DLL 78. The body of this post request will 
contain, at a minimum, the encrypted blob generated by the URL encryption object 74. 
For fully individualized copies (level 5 protected) this post request will also contain the 
activation certificate required when sealing the XrML license (see below). 

25 During step 2, the ISAPI 78 extracts, from the body of the POST, the 

Retailer ID, which is required for fetching the symmetric key 75 associated with this 
retailer for decrypting the URL. It then decrypts and validates the download request. If 
the request is invalid and/or the TTL computed has expired (e.g., a possible play-back 
attack), the download server may redirect the browser back to the bookstore site. The 

30 bookstore site 71 should always be encapsulated in the HTTP REFERRER server 
variable. During this step, an optional friendly filename may be provided via the 
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encrypted blob. This string, when returned, will be used by the ISAPI as the filename 
when downloading the LIT title to the end-user. 

At step 3, the ISAPI 78 passes the Book ID and Book ID type to the 
content store plug-in module, which then returns the physical location of the LIT file on 
5 the content store based on either a memory cache entry (if the LIT file being requested 
had been previously downloaded) or a lookup on the fulfillment database 89. 

At step 4, if the Book ID is not found on the local memory cache of the 
ISAPI 78, the LIT file is retrieved fi-om the content store 80 and copied into the local 
memory cache of the ISAPI. When the ISAPI caches the LIT files locally, it strips the 
LIT files from their symmetric keys 14A and stores them on a separate cache bucket, 
indexed by their respective ID, which may increase security. 

At step 5 the ISAPI 78 will perform one of these possible steps in 
accordance with the DRM level required for the LIT file bemg downloaded: 

If the request is for a DRM level 1 file, or the LIT file is not source sealed 
in the content store 80, the lASPI preferably retums an error, indicating that the proper 
error condition (invalid request or an invalid title in the content store, respectively). 

For source sealed (level 2) titles, the ISAPI return the file to the end-user, 
with no processing done on the file whatsoever. This is similar to downloading any other 
static file. 

For individually sealed titles (level 3), the user's name will be inserted 
into a new stream m the LIT file, the meta-data stamped with level 3 (for use by the 
reader client 90 or 92), the new meta-data is hashed, and the symmetric key 14A used to 
encrypt the LIT file is sealed with the new cryptographic hash value computed. 

For fiiUy individualized titles (level 5), the ISAPI 78 will, in addition to 
generating the functions note above for level 3, post a request to the licensing module 77, 
which will generate a license XrML blob, sign it with the fiilfillment center's certificate, 
seal it with the end-user's activation public key, and retum it for embedding in the LIT 
file. 

For both levels 3 and 5, all processing is carried out in the temporary 
memory space created during step 4. This memory space will be later discarded by the 
ISAPI, when the download is complete. 
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At step 6 the ISAPI DLL returns the LIT file to the nS server 76 for 
download. If, during step 3, the content store plug-in module returned a "Friendly 
Name" string, this value is used in the HTTP header as the filename to be stored in the 
user's machine. 

5 At step 7 the LIT file is downloaded by IIS to the end-user via HTTP. 

When the download is complete, IIS will call back into the ISAPI DLL 78 to notify that 
the pending request was fiilfiUed and the connection closed. The ISAPI 78 will then 
purge all temporary memory used during step 5. 

At step 8, the ISAPI DLL 78 will use the asynchronous fiilfillment 
1 0 pipeline (via the local MSMQ Independent Client 86) to log the transaction into the 
logging database 91 for later reporting and/or billing. This pipeline is also used to 
invalidate cache entries in the memory of the ISAPI asynchronously, such that any 
modifications to content store 80 performed by content management tool 82 will cause 
the ISAPI to invalidate the cached data and fall back to the plug-in module 88 (and 
15 subsequently the content store 80) to retrieve the LIT file for the invalidated cache entry. 

Once the eBook title has been downloaded to the client (after step 7), the 
reader client may be launched. This is enabled via a file-extension association of LIT to 
the reader. The reader may move the file into the local library folder (e.g., 
"C:\MyLibrary") and open the book to its cover page, which for level 3 titles, clearly 
20 identifies the owner beneath the author's name. 

Content Management Fxmctionality 

Once of the steps in securing the content in a DRM environment is the 
pre-encryption of the source files (LIT files) using symmetric keys 14A generated by the 
encryption tool. This process enables the download server 76 to seal the synunetric key 

25 14A according to the requirements of each DRM Level. The fiilfillment center 73 is 
responsible for populating the content store 80 according to their existing coding and 
cataloguing infirastructure. The fulfillment center 73 is also responsible for 
communicating the Book ID, Book ID Type, and their associated metadata to the 
retailers hosting bookstores that point to the content provider's site for fixlfilhnent, 

30 In accordance with a feature of the present invention, there may be 

independence between the download server 76 and the fiilfillment center's content store 
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servers 80. Every Book ID/Book ID Type pair that comes on the URL provided by the 
retailers 71 will be resolved into a physical path to a LIT file via the content store plug-in 
module 88, which can be customized by each fulfillment center 73. This provides for 
maximum flexibility and scalability of the content store repository as well as the 
5 download server ISAPI DLL 78. 

A bookstore (retailer) database is populated with the Book IDs generated 
by a tool for managing the LIT files of a particular content provider's data center. This 
process is assumed to take place asynchronously and via contractual agreement between 
the retailer 71 and the content provider (fulfilknent center) hosting the content servers 
10 76. These IDs will be provided to the download server ISAPI DLL 78 via the LIRL (in 
the encrypted portion of the URL). 

Design Considerations 

Exemplary schemas for the various tables used on the DAS Databases are 
described below. The exemplary schemas are not to be considered as limiting the present 
15 invention, as other schemas are possible. 

Fulfillment Database 

There are three tables in the exemplary fulfillment database. They include 
an DAS_Product table that contains all the information required to process a download 
request, an DAS_Registered_Retailers that contains all the information on retailers that 
20 are allowed to fulfill titles using this fulfillment installation of DAS, and an 
DAS_Licensor_Config that contains the required Licensor License provided by 
Microsoft for each DAS installation Partner. There are no relationships required between 
these tables; however, if table relationships are necessary, then each table's unique 
identifiers (primary keys) are used. 

25 

D AS_Product Table 

( 

D AS_BookID_Path_Mapping_nD int not null IDENTITY( 1,1), 

BookID varchar(256) not null. -- example "0-20 1 -63446- 

30 5" 

BooklDType varchar(32) not null, ~ example "ISBN" 
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Title 

Apes" 

Publisher 

Books" 

5 UNCPath 
"\\Store\taizan.lit" 

Price 



varchar(256) not null, 
varchar(256) not null, 
varchar(256) not null. 



10 

updated 

created 
15 ) 



varchar(32) not null, 
PriceStructure varchar(32) not null, 
Currency varchar(lO) not null, 

SecurityLevel varchar(32) not null, 
DateUpdated datetime null DEFAULT (getDateO), 

DateCreated datetime null DEFAULT (getDateQ) 



" example "Tarzan of the 

example "Ballantine 

-- exan^le 

example "6.59" 
-- example "Retail" 
-- example "USD" 

— example "5" 

— last time row was 

— time when row was 



DAS_Registered Retailers Table 

This table contains the Retailer E) and secret string that is used when 
20 computing the symmetric key 75 used to encrypt/decrypt URLs for fulfillment. Each 
string must match the string used by the retailer when installing the URLEncrypt COM 
object, since that's how each download request is authenticated. 



25 



DAS_Registered_Retailers_ID 
RetailerlD 



888" 



RetailerName 

Noble" 

30 RetailerDesc 
retailer" 

SharedSecret 
"Making_eBooks_Happen" 

DateUpdated 
35 DateCreated 
) 



int not null IDENnTY(l,l), 

varchar(256) not null, -- example "Retailer- 1 1 1 - 

varchar(256) not null, - example "Barnes & 

varchar(4096) not null, ~ exan^)le "Book 

varchar(256) not null, —example 

datetime null DEFAULT (getDate()), 
datetime null DEFAULT (getDateQ) 
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DAS_Licensor_Config Table 

This table contains the configuration settings for the licensing component 
of the download server. When the server starts, the licensor's certificate and licensor's 
5 private key are read out of this table and used to generate Level 5 licenses for LIT files. 
It is preferable to store this information on the SQL server because the data is too large to 
be stored in the local registry of the download server, and because of security concerns 
that the private key of retailers may be compromised if stored in a flat file. It also allows 
for easy changes to the download server configuration parameters, since DAS partners 
10 only have to modify this table in the fulfillment database 89 and all download servers 
will pick-up the change (via the asynchronous fulfilhnent pipeline and messaging 
component), simplifying management. 
( 

DAS_Licensor_Config_ID int not null IDENTITY(1,1), 

1 5 LicensorCertificate varchar(4096) not null, - signed licensor's 

certificate 

LicensorPrivateKey varbinaiy(350) not null, ~ binary form of 

licensors private key 

DateUpdated datetime null DEFAULT (getDateQ), 

20 DateCreated datetime null DEFAULT (getDateQ) 

) 

Logging Database 

The logging database 91 is used to log of all download requests. As the 
25 download servers process requests, the asynchronous fulfillment pipeline (based on 
MICROSOFT® Message Queue Server) is used to write, via a COM Object resident on 
the fiilfilhnent database server, each message fi-om the queue into the DAS_Log table. 
This will allow the DAS sites to audit their fiilfilhnent, and determine how many 
downloads took place, and when, and what are the most frequently downloaded titles, 
30 etc. This table may also be used for billing purposes. The logging database comprises a 
single table (DAS_Log) that contains all the transaction logging records fi-om 
downloaded titles. 
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DAS_LogJD 


int 


not null E)ENTITY(1,1). 


Bookid 


varchar(64) 


not null, 


example "0-201-63446-5" 


BookldType 


varchar(32) 


not null, 


- example "ISBN" 


SecurityLevel 


varchar(32) 


not null, 


-- example "5" 


NameOfFile 


varchar(256) 


not null, 


- example "Alice30.lit" 


CustomerlD 


varchar(256) 


not null, 


- example "34235433" 


UserName 


varchar(256) 


not null. 


- example "Pavel Zeman" 


Transactionid 


varchar(256) 


not null. 


example "123-456-789" 


License 


varchar(4096) 


null. 


— only for Level 5 content 



- text of the License 



RetailPrice varchar(32) 


null. 


example "$6.59" 


Cost varchar(32) 


null, 


-- example "$5.59" 


MSRP varchar(32) 


null, 


example "$7.59" 


DownloadAgentvarchai(256) 


null, 


- example "Mozzilla" 


IPAdress varchar(32) 


null. 


— example 



"123.456.789.000" 

DateLogged datetime null DEFAULT (getDate()) 

) 

20 

Activation Database 

The activation database 102 hosts all the required information for 
activating readers as well as configuration information to operate the activation servers. 
There are five tables in the activation database. The Key_Pairs table holds the key pairs 

25 used when generating activation certificates. The Users table hosts the PASSPORT™ 
credentials for each activated user, along with the key pair ID (link into the Key^Pairs 
table) and date of first Activation. The UsersDevices is a list of all Hardware IDs (i.e., 
Machine IDs) activated by all users. In order to identify which machine is being 
referenced, this table has a primary-key constraint on UserNum (an internal 

30 representation of each user on the Users table) and MachID (the computed machine ED). 
The KeyPtr tracks the number of key pairs used firom Key_Pairs table. It also points to 
the next available key pair to be used. The AS_DB_Config holds configuration elements 
for the database and the activation servers 94. 
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Key_Pairs Table 



10 



( 



ID_Key_Pair 

PublicKey 

PublicKeyXML 

PrivateKey 

BinaryPrivateKey 

AssignedToReader 

DateAssigned 
DateCreated 



int 

KeyValue 

KeyValue 

KeyValue 

BinKeyValue 

tinyint 

smalldatetime 
smaildatetime 



not null UNIQUE IDENTTTY(1,1), 
not null, 
not null, 
not null, 
not null, 

null DEFAULT(0), 
/* link to UsersDe vices. ID_UsersDevice */ 
null DEFAULT (NULL), 
null DEFAULT (getDate()) 



15 



20 



Users Table 
( 

UserNum 

FullName 

Email 

Userld 

DateMade 

ID_KeyPair 

) 



int 

varchar(60) 
varchar(60) 

varchar(60) 
smalldatetime 
int 



not null UNIQUE IDENTITY(1,1), 

null, 

null, 

not null PRIMARY KEY, 
null DEFAULT (getDateQ), 
not null 



UserDevices Table 



25 ( 



30 



UsersDeviceNum 

Machid 

UserNum 

DateRegistered 

ID_KeyPair 

TimesRegistcred 



mt 

varchar(255) 

int 

smalldatetime 

int 

int 



not null UNIQUE IDENTITY(l,l), 
not null, 

not null, 

null DEFAULT (getDate()), 
not null, 

null DEFAULT (0), 



CONSTEIAINT PC_UNQ PRIMARY KEY (UserNum, Machid) 
) 



35 KeyPtr Table 
( 
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NextKeyToUse int not null 

) 

AS_DB_Config Table 
5 ( 

/* when number of free keys drop below this number a scheduled GenKey job is adding 

keys */ 

MinKeysAvailable int not null, 

10 /* initially user can activate this many PCs */ 

MaxPCperUser int not null, 

/* if user reached limit above, but this period has elapsed since his last Activation, user 
can add one more */ 

15 GrantExtraPCPeriodlnDays int not null, 

/* to prevent DOS (denial of service) attacks by re-Activation of same PC over and over, 
tiiis can be set in production to a low value (e.g. 3), but test can set it to high for stress tests */ 
MaxSamePCregistrations int not null 

20 ) 

DRM Storage v/ithin LIT files 

Every LIT file is in effect a small file system, consisting of a collection of 
storage elements and their associated streams. At the root of every LIT file is a dedicated 

25 storage object for DRM. The sub-streams of the DRM storage object will vary depending 
on the DMR level via which the LIT file was distributed. In a level 5 protected LIT file, 
a Data Store contains the actual content of the eBook, and a DRMStorage Store contains 
all DRM-specific binary data. The DRMStorage Store will include ValidationStream, 
DRMSource, and DRMSealed streams (for Source and Individually Sealed copies). For 

30 fiiUy individualized titles, the LIT file will also include the licenses stream, which 
includes one End-User-License (EUL). 
License Format 

Below is an exemplary License, which is used for every download of fiilly 
individualized titles. The license is a construct that defines the rights that the user can 
35 exercise upon purchase of the title, in addition to defining the requirements for unsealing 
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the symmetric key to exercise those rights. Examples of "rights" that could be 
represented in the license are rendering the content (e.g., in the example of text content, 
reading it on the monitor of a PC), printmg the content, or copying-and-pasting portions 
of the content. It is noted that the exemplary license format is not intended to limit the 
5 scope of the present invention as other license formats having greater or lesser 

information are possible, as are licenses having license information in different formats. 

It is preferable that language chosen to represent a License is XML, and 
the format of the License is based on the Extended Rights Markup Language (XrML) 
specification. This is a well-suited markup language to describe usage rights in a flexible 

10 manner. XrML also provides for great interoperability and may allow for any technology 
investments made on components that generate and manage these licenses to be 
leveraged long-term. In a preferred embodiment, only those expressed in the license are 
granted to the license - i.e., if a right is not expressly granted, it is denied. However, it 
will be appreciated by those skilled in the art that other arrangements are possible, such 

15 as where a default set of rights is presumed unless expressly denied or modified by the 
Ucense. 

The top-level tags in a collapsed format are as follows: 

<?xml version="1.0" ?> 

<!DOCTYPE XrML SYSTEM "xrml.dtd"> 
20 - <XrML> 

- <BODY type="LICENSE" version="2.0"> 
<ISSUED>2000-01-27T15:30</ISSUED> 

+ <DESCRIPTOR> 

- <!" 

25 --> 

- <!" Licensed Book 

— > 
"> 

30 ± <WORK> 



Components of the book 
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10 



</XrML> 

35 



One chapter, and one image with digest 
value 



Usage rights of the book 



--> 

- <!" Licensor of the book 

15 --> 

- <!" ===== 

--> 

+ <LICENSOR> 

- <[.. === 



20 "> 

- < !— Licensees of the book 

--> 

- <!-- ==== 



--> 

25 + <LICENSEDPRIIMCIPALS> 

</BODY> 

- <!" — 

> 

- < !— Signature of the License Body 

30 "> 

- <!— ================== 

> 



+ <SIGNATURE> 
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The first line of the XrML structure above defines the version of the XML 
language used to create the XrML License. The second line specifies the name of the 
DTD file used to parse the XML file. The BODY tag provides the type of license, the 
version of the XrML specification used when the license v^as generated, and the date 
when it was issued. It is also the meta-tag for the whole license, which has the following 
sub-sections: WORK, LICENSOR, LICENSEDPRINCIPALS, and SIGNTURE, WORK 
contains all the semantic information about the license, including the usage RIGHTS. 
The contents of this field (including the tags) constitute the data that is hashed and 
signed. LICENSOR contains information pertaining the entity that issued the license, 
usually a retailer. LICENSEDPRINCIPALS contains a series of principals that must be 
authenticated when exercising the usage rights specified in a license. SIGNATURE 
contains the hash/digest of the LICENSEBODY as well as information about how the 
hash was created, including the algorithm used. It also includes the DIGEST encoded in 
accordance with the algorithm named by the Licensor when issuing the License. The 
DIGEST and SIGNATURE tags provide the authentication information used to validate 
the entire license in a way that cannot be tampered with. 

Structure of the BODY tag 

The main tag of an XrML License construct is the BODY tag, which 
contains the following tags: 

- <BODY type="LICENSE" version="2.0"> 
<ISSUED>2000-01-27T15:30</ISSUED> 

- <DESCRIPTOR> 

2 <OBJECT type="self-proving-EUL"> 

<ID type="MS-GUID">7BD394EA-C841-434d- 
A33F-5456D5E2AAAE</ID> 
</OBJECT> 
</DESCRIPTOR> 

- <!- ---> 

- <!" Licensed Book 

> 

- <!-== --> 

- <WORK> 
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<OBJECT type="BO0K-LIT-FORMAT"> 

<ID type="ISBN">8374-39384-38472</ID> 
<NAME>A book of James</NAME> 

</OBJECT> 

<CREATOR type=:"author">James the 

first</CREATOR> 
<CREATOR type="author">James the 

second </CREATOR> 
<OWNER> 

- <OBJECT type="Person"> 

<ID type="US-SSN">103-74-8843</ID> 
<NAME>Mike the man</NAME> 
<ADDRESS 

type="email">mike@man.com</ADDRE 
SS> 
</OBJECT> 

- <PUBLICKEY> 

< A LGO RITH M > RS A- 5 1 2 </ ALG O RITH M > 

- <PARAMETER name="public exponent"> 

<VALUE 

encoding="integer32">65537</VAL 
UE> 
</PARAMETER> 

- <PARAMETER name="modulus"> 

<VALUE encoding="base64" 

size="512">u+aEb/WqgyO+aDjgYL 
xwrktqFDR4HZeIeRlg+G5vmKNZRt 
9FH4ouePWz/AJYnn2NdxoJ6mcIIAQ 
Ve6Droj2fxA= = </VALUE> 
</PARAMETER> 
</PUBLICKEY> 
</OWNER> 

<!-- - --> 
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< !— Components of the book 
--> 

< ! — One chapter, and one image with digest value — > 
<u. --> 

<PARTS> 

- <WORK> 

- <OBJECT type="Chapter"> 

<ID type="relative">0</ID> 
<NAME>Chapter 1</NAME> 
</OBJECr> 
</WORK> 

- <WORK> 

- <OBJECT type="Image"> 

<ID type="relative">l</ID> 
<NAME>Image 1: Photon Celebshots 
Dogs</NAME> 
</OBJECT> 

- <DIGEST sourcedata="LicensorMeta"> 

<ALGORITHM >SHA1 </ALGORITHM > 
- <PARAMETER name="codingtype"> 
<VALUE 

encoding="strlng">surface- 
coding</VALUE> 
</PARAMETER> 
<VALUE encoding="base64" 

slze="160">OtSrhD5GrzxMeFEm8q 
4pQICKWHI=</VALUE> 
</DIGEST> 
</WORK> 
</PARTS> 

<!- --> 
< ! " Usage rights of the book 
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<RIGHTSGROUP name="Main Rights"> 

<DESCRIPnON>Some desc</DESCRIPnON> 

- <BUNDLE> 

- <TIME> 

<FROM time="2000-01-27T15:30" /> 
<UNTIL time="2000-01-27T15:30" /> 
</nME> 

- <ACCESS> 

- < PRINCIPAL sequence="2"> 

- <ENABLINGBITS type="sealed- 

des-key"> 

<VALUE encoding="base64" 
size="512">lnHtn/t2dp3u 
+ZqLkbd7MK0K4xR4YdSX 
aEvuk2Loh9ZR3EcPzCw+x 
M7zbPrJb6ESj70+B2fWTcx 
XDD+6WUB/Lw= = </VALU 
E> 

</ENABLINGBrrS> 
</PRINCIPAL> 
</ACCESS> 
</BUNDLE> 

- <RIGHTSLIST> 
2 <VIEW> 

- <ACCESS> 

- <PRINCIPAL sequence="2"> 
- <ENABLINGBITS 

type="sealed-des-key"> 
< VALUE 

encoding="base64" 

size="512">lnHtn/t2d 

p3u+ZqLkbd7MK0K4x 

R4YdSXaEvuk2Loh9Z 

RJEcPzCw+xM7zbPrJb 
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6ESj70+B2fWTcxxDD 
+6WUB/Lw= = </VAL 
UE> 

</ENABLINGBrrS> 
</PRINCIPAL> 

<PRINCIPAL sequence="3" /> 
</ACCESS> 

- <ACCESS> 

- <PRINCIPAL type="licensor"> 
; <ENABLINGBITS 

type="sealed-des-key"> 
<VALUE 

encoding="base64" 

slze="512">lnHtn/t2d 

p3u+ZqLkbd7MK0K4x 

R4YdSXaEvuk2Loh9Z 

RJEcPzCw+xM7zbPrJb 

6ESj70+B2fWTcxxDD 

+6WUB/Lw= = </VAL 

UE> 

</ENABUNGBITS> 
</PRINCIPAL> 
</ACCESS> 
</VIEW> 

<PRINT maxcount="5"> 

- <FEE> 

- <MONETARY> 

- <PERUSE value="5.00"> 

<CURRENCY iso- 
code="US*D" /> 
</PERUSE> 

- <ACCOUNT> 
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<ACCOUNTFROM 
id="BA-0234- 
0928392" /> 
< HOUSE id="XYZ" 
url="http://somehous 
e.com/payme.asp" /> 
</ACCOUNT> 
</MONETARY> 
</FEE> 
<TRACK> 

<PROVIDERNAME>e- 

tracker</PROVIDERNAME> 
<PR0VIDER1D id="US1023" 
type="Tracker ID" /> 

- < PARAMETER name="tracking 

address"> 
< VALUE 

encoding="url">"http://so 
metrackingservice/trackm 
e.asp"></VALUE> 
</PARAMETER> 

- <PARAMETER name="tracking 

support address"> 
<VALUE 

encoding="url">"http://so 
metracki ngservice/su pport 
nne.asp"></VALUE> 
</PARAMETER> 
</TRACK> 
<TERRITORY> 

< LOCATION country="us" 

state="C::A" city="EI Segundo" 
postalcode="90245" /> 
<LOCATION country="jp" /> 
</TERRITORY> 
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</PRINT> 
</RIGHTSLIST> 
</RIGHTSGROUP> 
</WORK> 

<!- --> 
< ! — Licensor of the book — > 

<!-- = "> 

<LICENSOR> 

- <OBJECT type="Principal-Certificate"> 

<ID type="MS-GUID">7BD394EA-C841-434d- 

A33F-5456D5E2AAAE</ID> 
<NAME> Barnes and Noble</NAME> 
</OBJECT> 

- <PUBLICKEY> 

< ALGORITH M > RSA- 512 </ALGO RITH M > 
2 <PARAMETER name="public exponent"> 
<VALUE 

encoding="integer32">65537</VALUE> 
</PARAMETER> 

- <PARAMETER nanne="modulus"> 

<VALUE encoding="base64" 

size="512">u+aEb/WqgyO+aDjgYLxwrk 
tqFDR4HZeIeRlg+G5vmKNZRt9FH4oueP 
Wz/A3Ynn2NdxoJ6mcIIAQVe6Droj2fxA= 
= </VALUE> 
</PARAMETER> 
</PUBLICKEY> 
</LICENSOR> 

<!-- --> 
< ! — Licensees of the book — > 

<!„ — - --> 
<LICENSEDPRINCIPALS> 

- <PRINCIPAL> 

- <OBJECT type="program"> 
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<ID 

type="msprogld">XrML.interpreter</ID 
> 

<NAME>DRPL INTERPRETER</NAME> 
/OBJECT> 

AUTHENTICATOR type="drm-nnoclule- 
verifier"> 

<ID type="microsoft- 

progid">ms.drm.authenticode</ID> 
<NAME>DRMAuthenticode</NAME> 
<AUTHENTICATIONCLASS> 

<VERSIONSPAN min="2.0" max="3.4" 
/> 

<VERSION>5.0</VERSION> 

< S ECURITYLEVEL> 5 </S ECU RITYLE 
VEL> 

</authentic:ationclass> 

<VERIFICATIONDATA type="signature- 

key"> 
- <PUBLICKEY> 

<ALGORITHM>RSA- 
512</ALGORITHM> 

- <PARAMETER name="public 

exponent" > 
<VALUE 

encoding="integer32">65 
537</VALUE> 
</PARAMETER> 

- <PARAMETER name="modulus"> 

<VALUE encoding="base64" 
size="512">u+aEb/Wqgy 
0+aDjgYLxwrktqFDR4HZe 
IeRlg+G5vmKNZRt9FH4o 
uePWz/AJYnn2NdxoJ6mcII 
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AQVe6Droj2fxA= = </VALU 
E> 

</PARAMETER> 
</PUBLICKEY> 
</VERinCATIONDATA> 
</AUTHENTICATOR> 
</PRINCIPAL> 
<PRINCIPAL> 

- <OBJECT type="MS Ebook Device"> 

<ID type="INTEL SN">Intel PII 92840- 

AA9-39849-00</ID> 
<NAME>Johns Computer</NAME> 
</OBJECT> 

- <AUTHENTICATOR type="drminternal- 

ce rtve r ify- p rog ra m " > 

<ID type="microsoft-progid">2323-2324- 
abcd-93al</ID> 

- <AUTHENTICATIONCLASS> 

<VERSION>l,x-2.5</VERSION> 
</AUTHENTICATIONCLASS> 

- <VERIFICATIONDATA type="authenticode- 

named-root"> 
- <PUBLICKEY> 

<ALGORITHM>RSA- 
512</ALGORITHM> 

- <PARAMETER name="public 

exponent" > 
<VALUE 

encoding="integer32">65 
537</VALUE> 
</PARAMETER> 

- <PARAMETER nanne="modulus"> 

<VALUE encoding="base64" 
size="512">u+aEb/Wqgy 
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0+aDjgYLxwrktqFDR4HZe 
IeRlg+G5vmKNZRt9FH4o 
uePW2/AJYnn2NdxoJ6mcII 
AQVe6Droj2fxA= = </VALU 
E> 

</PARAMETER> 
</PUBLICKEY> 
</VERIFICATIONDATA> 
- < VERIFICATION DATA> 

- <PARAMETER name="bbid"> 

< VALUE 

encoding="string">xxzzy</VAL 
UE> 
</PARAMETER> 

- <PUBLICKEY> 

<ALGORITHM>RSA- 
512</ALGORITHM> 
- <PARAMETER name="public 
exponent"> 
<VALUE 

encoding="integer32">3< 
/VALUE> 
</PARAMETER> 
2 <PARAMETER name="modulus"> 
<VALUE encoding="base64" 
size="90">33845URT2039 
87= = </VALUE> 
</PARAMETER> 
</PUBLICKEY> 
</VERIFICATIONDATA> 
</AUTHENTICATOR> 
</PRINCIPAL> 
<PRINCIPAL> 

- <OBJECT type="applicatlon"> 
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<ID type="MS PROG- 

ID">43984938476jshd</ID> 
<NAME>MS Book Reader 2.0</NAME> 
</OBJECT> 

5 - <AUTHENTICATOR type="drminternal-digest- 

program"> 

<ID type="microsoft-progid">2323-2324- 
abcd-93al</ID> 

- <AUTHENTICATIONCLASS> 

10 <VERSION>l.x-2.5</VERSION> 

</AUTHENTICATIONCLASS> 

- <VERIFICATIONDATA type="authenticode- 

named-root"> 
- <DIGEST> 

15 

<ALG0RITHM>MD5</ALG0RIT 
HM> 

<VALUE encoding="base64" 
size="90">bXlwYXNzd29yZA= 
20 =</VALUE> 

</DIGEST> 
</VERIFICATIONDATA> 
</AUTHENTICATOR> 
</PRINCIPAL> 
25 </LICENSEDPRINCIPALS> 
</BODY> 



License Authenticity 

As mentioned before, the reader secure repository authenticates a license 
30 via the SIGNATURE and DIGEST tags. This is such that the client software can validate 
that the content being rendered came from a trusted source. A more detailed example of 
these tags is provided below: 

- <!— -^^ ■ . = 

Signature of the License Body 
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- <SIGNATURE> 
5 - <DIGEST> 

< ALGORITHM > SH AK/ALGORITH M > 
- <PARAMETER nanne="codingtype"> 
<VALUE encoding="string">surface- 
coding</VALUE> 
10 </PARAMETER> 

<VALUE encoding="base64" 

size="160">OtSrhD5GrzxMeFEm8q4pQICKW 
HI=</VALUE> 
</DIGEST> 

15 <VALUE encoding="base64" 

size="512">A7qsNTFT2roeL6eP+IDQFwjIz5XSFBV 
+NBF0eNa7de+lD6n+MPJa3J7ki8Dnnwmuu/pBciQ 
nJ4xGaqRZ5AYoWRQ==</VALUE> 
</SIGNATURE> 

20 

DRM System Content Sources Scenarios 

The source content is preferably distributed in Open eBook ("OEB") 
format, which will be later customized by the Retailer to each target Reader. The OEB 
format is specified in the document entitled Open eBook™ Publication Structure 1.0 , 
25 dated September 16, 1 999, which available at 

http://www.openebook.org/specification.htm and is expressly incorporated herein by 
reference in its entirety. 

Content Sources Scenarios 

Within the context of the DRM System, content sources (authors and/or 
30 publishers) of eBooks are expected to provide either open (i.e., unsealed) or sealed 
copies that are ready for sale. In order to be distributed by the server described below, 
publishers must provide copies that have been at a minimum source sealed, or 
alternatively, the pubUshers may optionally provide source OEB/HTML files that the 



wo 01/44907 



PCT/USOO/33726 



-61- 

merchant/distributor will encrypt and store for fulfillment. The content sources may also 
provide a separate file (e.g., XML, text, database script, etc.) that will provide merchant- 
specific information about each title being distributed which will be used by the 
merchant/distributor to populate their fiilfilhnent databases. Such information may 
5 include the desired DRM level, pricing, teaser, etc. 

Because there is an expectation that a trust relationship between 
publishers and retailers is preferably maintained contractually and not technologically, it 
is generally not necessary to encryption and/or sealing titles between publishers and 
merchants/distributors. Such a relationship provides for a simpler deployment. If, 
10 however, added security is a concern, the present invention provides for titles that may 
be encrypted when transferred between publishers and merchants/distributors. 

In accordance with the present invention, publishers may distribute the 
content to retailers via one of delivery of portable mass-storage medium (CDs, DVDs, 
etc.); secure FTP servers in either the publisher or the merchant/distributor site; secure 
15 HTTPS (SSL) on either the publisher or the merchant/distributor site; and secure 

dedicated network coimections between the publisher and the merchant/distributor sites. 

Merchant/Distributor Scenarios 

Several non-limiting distribution scenarios will now be described. The 
scenarios are intended to provide examples of the of sales to customers, and is not 
20 intended to limit the present invention as other scenarios are possible. 
Sales of Source Sealed Copies 

After the buying customer has selected the titles he/she wishes to 
purchase and decides to complete an order, the merchant will process the order according 
to their existing methods (e.g., credit card validation, billing, etc.). This may include 

25 requiring the users to authenticate themselves (for those which require a membership 
record firom their customers) or simply fill out an order form. The merchant will next 
generate and download a receipt (electronic proof-of-purchase) to the buying customer. 
As noted above, it is preferable that the electronic receipt include all the information 
required to enable the user to later download the titles they purchased via a mechanism 

30 such as a URL that points to the content server 76 and contains the encrypted blob 
generated by the URL encryption object. Once the user clicks on the URL included in 
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the electronic receipt for downloading the title purchased, the server listed in that URL 
(i.e., the fulfillment or content server) downloads the referenced title to the purchaser. 
The content/download servers 76 may validate that the order was indeed placed by the 
user attempting to download the title. 
5 As previously mentioned, source sealed copies may indelibly include the 

name of the publisher and/or author and any^other rights that have been delegated to the 
merchant as part of the distribution process. The merchant/distributor uses tools to 
encrypt the title with a symmetric key 14A provided by those tools. These same tools 
will encrypt the symmetric key 14A with a cryptographic hash of the title's meta-data 

10 and embed the encrypted symmetric key 14A in a separate stream in the title. When the 
reader software opens these titles, it will apply the same algorithm used by the tool to 
decrypt the symmetric key and then use it to decrypt the content. It is noted that titles 
purchased in this manner may be easily re-distributed by the end-users (e.g., by posting 
the LIT file on the Web, or by saving it on magnetic disk 29 or optical disk 3 1 and 

15 sending the disk to another user); thus it is recommended that the merchant provide 
warnings regarding illegal distribution in every receipt. The ovmers of titles sold this 
way are encouraged to include copyright information as part of the publication. 
Sales of Individually Sealed Copies 

Similar to source sealed copies, individually sealed copies (e.g., level 3) 
20 require the retailer to name the rightful owner of the title in the meta-data, and then seal 
the symmetric key 14A used for encryption/decryption of the content with a new 
cryptographic hash of the new meta-data, which now includes the owner's name. This 
advantageously makes the meta-data tamper-resistant, since any attempt to change the 
meta-data (e.g., remove the rightful owner's name so that the rightful owner could 
25 distribute the copies and escape detection) would cause any attempt to unseal the 
symmetric key 14A to fail, because the wrong cryptographic hash would result. 
However, like unsigned and unsealed copies, and like source sealed copies, these titles 
do not provide any pro-active copy protection; instead, individually-sealed copies protect 
the owner's rights in the works by relying on the deterrent effect that a user whose name 
30 is bound to the copy and who engaged in illegal distribution of the copy could be easily 
discovered. 
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In the scenario, the retailer generally provides the consumer's name, as it 
appears on his/her credit card, as a parameter on each download URL included in the 
receipt (i.e., proof of purchase) page/e-mail. This information is used by the download 
servers 76 during fulfilhnent to add the user's name to the meta-data. Use of the name 
5 associated with a credit card is preferably, because, assuming that the credit card is not 
stolen, it is a reliable source of the user's name; if the name provided by the retailer is 
based on, say, user input, there is a greater danger that the user would enter a fake name 
that would not serve the goal of binding the user's real name to the copy. 

Sales of Signed Copies 
10 Signed copies (e.g., level 4) are titles that include a digital signature, 

which was provided by the content source (author and/or publisher) at the time the title 
was generated. This is the mechanism used to provide authenticatable copies, by having 
the data in the LIT file (or a portion thereof) signed by various entities in the distribution 
chain. Level 4 can be combined with other levels - e.g., it is possible to combine source 
1 5 signing with either level 3 or level 5 individualization in order to create a title that is both 
authenticatable and copy-resistant (or, in the case of level 3, copy-"deterred"). 

Sales of Fully Individualized Copies 

Fully individualized copies differ fh)m individually sealed titles in that at 
the time of fulfillment, the merchant/distributor must always seal the license by 

20 encrypting the symmetric key 14A to the end-user's public key in the end-user's 
activation certificate. The public key's authenticity is attested to by the activation 
certificate, which is signed by the activation servers 94. A merchant may request the 
signed activation certificate the first time a particular consumer purchases any fully 
individualized title. Optionally, merchants could request such certificate on every 

25 transaction, if the user does not have a membership or other relationship witii the 
merchant. The encrypted activation certificate is provided to a retailer by a chent 
component of the DRM system, which can be scripted to via any web page. This 
certificate is encrypted to protect the privacy of the consumer as well as reduce the risk 
of playback attacks and/or hacking. It is preferable that merchants store the encrypted 

30 activation certificate on their sites for future transactions. 
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Titles sold as fiilly individualized copies may only be opened on the 
purchasing consumer's reader(s) and cannot be distributed openly. As part of the process 
of selling fiilly individualized titles, merchants may detect whether the end-user's reader 
has been activated, which is a requirement for downloading such titles. If a merchant 
5 detects that a reader is not activated, the merchant may advise the reader that activation is 
necessary to open a fiilly individualized title. In the case where the merchant does not 
store a particular user's activation certificate, it would not even be possible to provide a 
fully individualized title for that user. In the case where the merchant stores the 
activation certificate, the merchant may, for example, detect that the reader installed on 
10 the user's device through which the user is purchasing the title has not been activated 
(although that user may have other activated readers), in which case the merchant may 
provide the title to the user, but may advise the user that they must activate the new 
device in order to use the title on that device (subject, of course, to any applicable limit 
on activations). 

15 It is noted that the foregoing examples have been provided merely for the 

purpose of explanation and are in no way to be construed as limiting of the present 
invention. While the invention has been described with reference to various 
embodiments, it is understood that the words which have been used herein are words of 
description and illustration, rather than words of limitations. Further, although the 

20 invention has been described herein with reference to particular means, materials and 
embodiments, the invention is not intended to be limited to the particulars disclosed 
herein; rather, the invention extends to all functionally equivalent structures, methods 
and uses, such as are within the scope of the appended claims. Those skilled in the art, 
having the benefit of the teachings of this specification, may effect numerous 

25 modifications thereto and changes may be made without departing from the scope and 
spirit of the invention in its aspects. 
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CLAIMS 

WHAT IS CLAIMED: 

1 . A method of communicating with a first computing device, said 
method comprising the acts of: 

encrypting information destined for said first computing device; 
creating an HTTP request which includes an address of said first 
5 device and the encrypted information; and 

transmitting said HTTP request to a second computing device 
different fi"om said first computing device. 

2. The method of claim 1, wherein said HTTP request comprises a POST 
10 request, and wherein said encrypted information is included in the body of said POST 

request. 

3. The method of claim 1, wherein said HTTP request comprises a GET 
request, and wherein said encrypted information is appended to said GET request as a 

15 parameter. 

4. The method of claim 1, wherein said information is encrypted using a 
symmetric key, and wherein said symmetric key is a shared secret available to said first 
conlputing device and not available to said second computing device. 

20 

^ 5. The method of claim 1, further comprising the act of creating a web 
page which includes a hyperlink associated with said HTTP request, wherein said 
transmitting act comprises transmitting said web page to said second computing device. 

25 6. The method of claim 1 , wherein said second computing device is 

associated with a purchaser of content, wherein said first computing device provides said 
content, and wherein the encrypted information includes information relating to the 
purchase of said content. 
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7. The method of claim 6, wherein the encrypted information includes 
information which identifies said purchaser. 

5 8. The method of claim 1 , wherein the encrypted information includes a 

timestamp. 

9. The method of claim 1, further comprising the acts of: 

computing a hash of said information prior to encryption; 

10 and 

including said hash in said HTTP request. 

10. The method of claim 9, wherein said hash is computed using an SHAl 

algorithm. 

15 

11 . A computer readable medium having computer-executable 
instructions to perform the method of claim 1 . 

12. A method of commxmicating with a first computing device through a 
20 second computing device, said method comprising the acts of: 

encrypting information such that the encrypted information is 
decryptable by a secret; 

transmitting the encrypted information to said second computing 
device, said encrypted information being transmittable to said first computing device 
25 upon instruction firom a user operating said second computing device, wherein said secret 
is not accessible to either said second computing device or said user; and 

sharing said secret by performing either of the following acts: 

providing said secret to said furst computing device or to a 
party associated with said first computing device; or 
30 receiving said secret firom said first computing device or 

fi-om a party associated with said first computing device. 
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13, The method of claim 12, wherein said first computing device is 
associated with a purchaser of content, and wherein said second computing device 
provides said content, 

5 

14. The method of claim 13, wherein the encrypted information includes 
information relating to the purchase of said content. 



15. The method of claim 12, wherein said transmitting act comprises 
10 transmitting the encrypted information over a wide-area network. 

16. The method of claim 15, wherein said wide-area network comprises 

the Internet. 

15 17. The method of claim 12, wherein said transmitting act comprises 

transmitting to said second computing device an HTTP request which includes an 
address of said first computing device and the encrypted information. 



18. The method of claim 17, wherein said HTTP request comprises a 
20 POST request, and wherein said encrypted information is included in the body of said 
POST request. 



19. The method of claim 17, wherein said HTTP request comprises a GET 
request, and wherein said encrypted information is appended to said GET request as a 

25 parameter. 

20. The method of claim 17, further comprising the act of creating a web 
page which includes a link associated with said HTTP request, wherein said transmitting 
act comprising transmitting said web page to said second computing device, and wherein 

30 the user instruction to transmit the encrypted information to said first computing device 
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comprises the user using an input device associated with said second computing device 
to actuate said Hnk. 

21. The method of claim 12, wherein said secret comprises a symmetric 
5 key, and wherein said encrypting act comprises encrypting said information with said 

symmetric key. 

22. The method of claim 12, further comprising the act of including a 
timestamp in the encrypted information. 

10 

23. The method of claim 12, further comprising the act of appending a 
hash of said information to said encrypted information, said hash being computed prior 
to encryption of said information. 

15 24. A method of facilitating electronic content distribution comprising the 

acts of: 

providing, to a first party for use on a first computing device, a 
first set of computer-executable instructions which encrypts information based on a 
unique id that maps into a shared secret, the encrypted information being includable in an 
20 HTTP request which includes a network address of a second computing device; and 

providing, to a second party for use on said second computing 
device, a second set of computer-executable instructions which decrypts the encrypted 
information. 

25 25. The method of claim 24, wherein said first party comprises a seller of 

electronic content, wherein said second party comprises a provider of electronic content 
sold by said first party, and wherein said encrypted information relates to a transaction 
between said first party and a consumer of electronic content. 
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26. The method of claim 24, wherein said HTTP request comprises a 
POST request, and wherein said encrypted information is included in the body of said 
POST request, 

5 27. The method of claim 24, wherein said HTTP request comprises a GET 

request, and wherein said encrypted information is appended to said GET request as a 
parameter. 

28. The method of claim 24, wherein said first set of computer-executable 
10 instructions comprises a COM object. 

29. The method of claim 28, wherein said first set of computer-executable 
instructions exposes an ENCRYPT method for use by a third set of computer-executable 
instruction which runs on said first computing device. 

15 

30. The method of claim 24, wherein a secret symmetric key is accessible 
to or known by each of said first computing device and said second computing device, 
and wherein said first set of computer-executable instructions uses said secret symmetric 
key to encrypt said information. 

20 

31. The method of claim 24, wherein said information includes 
information identifying an item of content which said second computing device provides. 

32. The method of claim 24, wherein said information includes 
25 information identifying a purchaser of an item of content. 

33. A method of building a client-server request, said method comprising 

the acts of: 

encrypting first information so as to be decryptable by a secret 
30 accessible to a first server; 
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including an address associated with said first server in said client- 
server request; and 

including the encrypted information in said client-server request. 

5 34. The method of claim 33, wherein the encrypted information includes 

information relating to a transaction to purchase a content item, wherein said first server 
furthers at least some aspect of said transaction. 



35. The method of claim 34, wherein the encrypted information includes 
1 0 information which identifies a purchaser of said content item. 

36. The method of claim 34, wherein the encrypted information includes 
information which identifies said content item. 

15 37. The method of claim 34, wherein the encrypted information includes a 

timestamp. 

38. The method of claim 34, wherein said first server provides said 

content item, 

20 

39. The method of claim 33, wherein said secret comprises a symmetric 
key, and wherein the encrypted information is generated by encrypting cleartext 
information with said symmetric key. 

25 40. The method of claim 33, wherein said client-server request comprises 

an HTTP request. 

41 . The method of claim 40, wherein said HTTP request comprises a 
POST request, and wherein the encrypted information is included in the body of said 
30 POST request. 
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42. The method of claim 40, wherein said HTTP request comprises a GET 
request, and wherein the encrypted information is appended to said GET request as a 
parameter. 

5 43. A computer-readable medixun having computer-executable 

instructions to perform the method of claim 33. 

44. A method of distributing electronic content, said method comprising 

the acts of: 

10 receiving, at a first computing device from a second computing 

device, an order for a content item; and 

providing, from said first computing device to said second 
computing device, data comprising: 

a network address of a third computing device; and 
1 5 encrypted information; 

wherein said third computing device processes said order by using at least some of said 
encrypted information. 

45. The method of claim 44, wherein said data comprises an HTTP POST 
20 request, and wherein said encrypted information is included in the body of said POST 

request. 

46. The method of claim 44, wherein said data comprises an HTTP GET 

request. 

25 

47. The method claim 44, wherein said encrypted information includes 
information identifying said content item. 

48. The method of claim 44, wherein said encrypted information includes 
30 information identifying the individual who issued said order for said content item. 



wo 01/44907 



PCT/USOO/33726 



-72- 

49. The method of claim 44, wherein said encrypted information includes 

a timestamp. 

50. The method of claim 44, wherein said data further comprises a hash of 
5 said encrypted information, said hash being computed prior to encryption of said 

information. 

51. The method of claim 50, wherein said hash is computed using an 
SHAl algorithm. 

10 

52. The method of claim 44, wherein said content item does not reside on 
said first computing device. 

53. A computer-readable medium having computer-executable 
1 5 instructions to perform the method of claim 44. 

54. A computer-readable medium having computer-executable 
instructions for performing steps comprising: 

receiving parameters that identify characteristics of a first 
20 transaction between a first client and a first server; 

encrypting one or more of said parameters; 
returning said encrypted parameters to said first client in a format 
such that a second server may receive said encrypted parameters fi-om said first chent, 
validate said first transaction, and initiate a second transaction without any interaction 
25 with said first server. 

55. The computer-readable medium of claim 54, wherein said computer- 
executable instructions comprise a COM object. 

30 56. The computer-readable medium of claim 54, wherein said first 

transaction relates to the sale of electronic content. 
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57. The computer-readable medium of claim 56, wherein said second 
transaction comprises downloading said electronic content from said second server to 
said first client. 

5 

58. The computer-readable medium of claim 56, wherein said parameters 
comprise end-use information that enables the individualization of said electronic 
content. 

10 59. The computer-readable medium of claim 54, wherein said parameters 

include one or more of the following: information identifying a party to said first 
transaction, and information identifying an item purchased in said first transaction. 

60. The computer-readable medium of claim 54, wherein said steps 
15 further comprise including a timestamp in said encrypted parameters. 

61. The computer-readable medium of claim 54, wherein said steps 
further comprise computing a hash of at least some of said encrypted parameters. 

20 62. The computer-readable medium of claim 61, wherein said hash is 

computed using an SHAl algorithm. 

63. The computer-readable medium of claim 54, wherein said encrypting 
act comprises applying a secret symmetric key shared between said first server and said 

25 second server, 

64. The computer-readable medium of claim 54, wherein said format 
comprises an HTTP request including an address of said first server. 



30 
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